Resource Risk in Projects: Key Person Dependency

What is key person risk in a project?

Key person risk is the chance that losing one individual — temporarily or permanently — stops or seriously slows work that depends on them. It is a resource risk, not a people risk: the problem is not that the person might leave, it is that the project has no substitute for what they hold.

Three things make a dependency count as a real risk rather than an ordinary specialisation:

1. Concentration. One person holds something the work needs: a decision right, a credential, a mental model of a legacy system, or a customer relationship.
2. Substitution time. Replacing that contribution takes longer than the project can tolerate. A two-week gap that the schedule can absorb is not a risk; a two-week gap on the critical path is.
3. Low detectability. The dependency is invisible until it is exercised. Nobody notices that only one person can approve the schema change until the day they cannot.

Most teams discover all three at once, in the middle of an incident. The work of managing key person risk is mostly moving that discovery earlier.

How do you find key-person dependency before it finds you?

You find it with three cheap instruments: an absence test, a knowledge map, and a decision-rights audit. None requires software, and all three take less than a day.

The absence test

Ask one question about every critical activity: *who can take two unplanned weeks off without the work stopping?* Every activity with a single yes answer is a registered risk. Do not ask people whether they are a single point of failure — most will say no, honestly, because they underestimate how much context they carry. Ask about the work instead.

The knowledge map

List the project’s ten to fifteen critical capabilities — not job titles. Examples: “cut a production release”, “reconcile the vendor invoice against the contract”, “explain why the billing service retries twice”, “sign off the regulatory submission”. For each, write the primary owner and every person who could complete it unaided within one working day. Capabilities with one name deserve attention; capabilities with zero names are already a live problem.

The decision-rights audit

Many key-person risks are not about skill at all. They are about authority. If only one person can approve a change, sign a purchase, or accept a deliverable, the project is dependent regardless of how well documented the process is. Map the decisions, not just the tasks.

> Practical tip: Run the absence test the week before a major holiday, when half the team is already out. Dependencies are visible then, and the exercise costs nothing.

Why is the bus factor a useful measure — and a dangerous one?

The bus factor is useful because it turns a vague worry into a number you can compare across teams and quarters. It is dangerous because it is usually estimated from activity data that misses the places where knowledge actually lives.

The metric is defined as the minimum number of team members whose departure would leave the project unable to proceed. A bus factor of 1 means one person holds the project together; a bus factor of 4 means the project could absorb three losses. Research on open-source projects has repeatedly found the distribution skewed toward the dangerous end. A large-scale study of 36,464 GitHub projects, presented in *IEICE Transactions on Information and Systems*, found that 89% had lost their core development team at least once, and that most projects relied on a single core developer to keep development moving.

Two cautions matter when you apply this to a workplace project.

First, the automated versions measure commits, not knowledge. A 2022 study by researchers working with JetBrains surveyed 269 engineers and found the bus factor is perceived as a genuine problem, but that version-control data captures only part of how knowledge moves. Code reviews, design meetings, and informal pairing carry knowledge that never appears as an author line. Structured team judgement is often more accurate than a tool’s output.

Second, the number invites the wrong conversation. Reporting “our bus factor is 1” can make a key engineer feel labelled as a risk and everyone else feel undervalued, a pitfall the JetBrains researchers documented directly. Frame the finding around the *work*: “the release process has one owner” is actionable. “You are a single point of failure” is a performance review.

Which dependency type do you actually have?

This is the part mitigation plans skip. Teams default to “write it down”, then wonder why the risk survives the wiki page. Documentation addresses one of six dependency types.

Reading the table honestly usually changes the plan. If the dependency is judgement or relationship, a document will not fix it, and a well-written runbook will create confidence without capability — the most expensive outcome, because it looks like mitigation.

How much does key-person dependency cost?

Pricing the exposure is what moves it from a cultural concern to a funded control. Three calculations do most of the work.

Example 1: blocked capacity during an absence

A nine-person delivery team includes one integration architect who is the sole owner of three workstreams. She is unexpectedly unavailable for 15 working days. Four colleagues are partially blocked — call it 40% of their time for the duration — at a loaded rate of $850 per day.

• Blocked capacity: 4 people × 15 days × 0.40 = 24 person-days
• Direct cost: 24 × $850 = $20,400
• Plus one milestone carrying a contractual service credit of $35,000

The direct cost is survivable; the milestone credit is what makes the case to a sponsor. The calculation is also optimistic, because it assumes the team notices immediately.

Example 2: vacancy and ramp-up

A delivery lead earning $120,000 leaves with two weeks’ notice. Time to fill is 42 days and full productivity takes another three months, at an average of 70% output during ramp-up.

• Vacancy: 42 working days at a daily contribution of $120,000 ÷ 220 ≈ $545, so $22,890
• Ramp-up shortfall: 65 working days × 30% × $545 ≈ $10,627
• Team spillover: eight colleagues losing 14% productivity for 42 days, at an average loaded cost of $3,454 per team-day — 42 × 0.14 × $3,454 ≈ $20,310

Total exposure lands near $54,000 for one mid-level departure, before recruiting costs. The spillover line is the one teams forget, and here it is the largest single component.

Example 3: does the mitigation pay?

Suppose the chance of losing that architect within the year is 12%, and the modelled impact is $180,000. Expected annual loss is 0.12 × $180,000 = $21,600.

Now price the control: a second owner is trained through four months of pairing, two hours a week, at $110 per hour, plus 20 hours of documentation time at the same rate.

• Pairing: 4 months × 4 sessions × 2 hours × $110 = $3,520
• Documentation: 20 × $110 = $2,200
• Total: $5,720

That is roughly a quarter of the expected loss, for a control that also reduces future onboarding cost. It is the comparison that gets a risk treated as an investment rather than an overhead. If mitigation costs more than the expected loss, the honest answer may be to accept the risk or insure it instead.

What controls actually work?

Four controls cover most situations. They are listed in order of cost, and the cheap ones should be exhausted first.

1. Minimum viable documentation. Not a manual — a one-page card per critical capability with the trigger, the steps, the systems and files, the decision points, the exceptions, and the escalation path. A document that takes three weeks to write is out of date before it is read. One that answers “what do I do next” gets used.

2. Pairing and deliberate rotation. The backup does the work with the owner present, on real tasks with real deadlines. Quarterly rotation on the critical path beats any amount of reading. The cost is visible and immediate, which is exactly why it gets skipped.

3. Governed backup access. Credentials, permissions, and vendor contacts need a named secondary who has *tested* the route. Access that exists on paper but was never exercised fails at the worst moment — an MFA device, an expired role, a support contract that only recognises the named contact.

4. Succession coverage named in advance. For genuinely irreplaceable roles, name an internal successor and an external option before the gap exists. Contractual coverage that takes three weeks to activate is not coverage.

> Common mistake: Treating a successful holiday as proof of resilience. A two-week absence where the owner answers Slack messages every evening is not a test; it is a demonstration that the dependency is intact and the owner is willing to absorb the cost. The test only counts if the owner genuinely disengages.

How do you run a 30-day continuity test?

A continuity test converts assumptions into evidence in about a month, without a formal business continuity programme.

Judge success by whether the work continued, not by whether a document exists. Useful measures from the test week: how often the owner had to intervene, decision time against the baseline, exceptions that needed escalation, and whether the stakeholder noticed a difference.

Two rules make the test trustworthy. The owner must not quietly fix things afterwards, because silent rescue hides the gap the test was meant to find. And the backup must hold real authority for the week, not just the task list.

What are the common mistakes?

Documentation theatre. A wiki full of pages nobody has opened is not a control. Measure retrieval, not authorship: can the backup find the current version and act on it in ten minutes?

Confusing seniority with substitutability. A junior analyst who knows the data model may be a bigger single point of failure than a director who attends steering meetings. Map capabilities, not org charts.

Training without practice. A two-hour knowledge-sharing session transfers awareness, not skill. The person who heard the explanation will still need the owner when the exception appears.

What are the trade-offs?

Every control here buys resilience with something else, and honest planning says what.

There is also a retention effect. People who are the only holder of critical knowledge often feel trapped; people who are deliberately cross-trained often feel invested. Say which reaction you expect before you start, because a key person who reads a backup as a replacement will resist the programme.

Where does project software help?

Most of this work fails on upkeep, not insight. The dependency map is accurate the day it is written and stale three months later, because the project moved and nobody updated the owner column.

That is the narrow problem Doitify addresses: tasks, sub-tasks, owners, checklists, dependencies, and project documents live in one workspace, so the named backup sits next to the work rather than in a separate spreadsheet. Resource and workload views surface concentration — one person owning a third of the critical-path tasks is visible without a special audit. Doitify is our product, so read that as a description of fit rather than an independent review.

Conclusion

Key person risk is a scheduling problem wearing a personnel costume. The question is not whether someone is hard to replace in general, but whether a capability has a substitute within the time the project can wait.

Find the dependencies with an absence test and a capability map. Classify the type before choosing the control, because documentation solves knowledge and nothing else. Price the exposure so it competes with other risks on the register. Then test the mitigation with a real absence in which the owner does not rescue the backup — the only evidence that counts.

Teams that do this once usually discover two things: fewer dependencies than they feared, and one or two far more expensive than anyone assumed. Both findings are cheaper now than in the week the person resigns.

If this post on key person risk was helpful, you might also enjoy How to Start a New Project the Right Way and Capacity vs Availability in Project Management: Key Differences and How to Use Both.