Dependency, Risk and Escalation Management

The operational problem

Programming deliverables depend on things programmers do not control: decisions from statisticians and clinical teams, data from vendors and data management, environment access, reviews and sign-offs. When one of them slips, the slip is usually discovered at the receiving end, and as a surprise.

Most teams do have a risk register. It is filled in once, reviewed rarely and consulted never. Escalation then happens one of two ways: too late ("it is a crisis now") or too noisily (everything is red). In both cases the person who has to decide gets a problem, not a decision to make.

Three different things are routinely mixed together, and the mix is where ownership gets lost.

• A dependency is something you need from someone else by a date.
• A risk is an uncertain event that may affect an objective.
• An issue is a risk that has already happened.

Practical methodology

1. Keep dependencies, risks and issues separate

A dependency becomes a risk when the date is uncertain, and an issue when it is missed. Moving an item from one kind to another is the event worth noticing.

2. Write each dependency with a provider, a receiver and two dates

Record who provides it and who receives it, and the provider's acknowledgement that they have taken it on. Record two dates: the need-by date (the plan) and the latest acceptable date (the last day it can arrive and still be absorbed), using the same calculation as the lock chapter:

latest acceptable date = milestone date
    - (time to absorb: reconcile + implement + independent QC + review + buffer)

The gap between the two dates is the float. When the provider's forecast lands after the latest acceptable date, a dependency has already become a risk.

3. Write risks as cause, event and consequence

A topic ("data delays") cannot be owned or treated. A statement can:

Because the central laboratory has not confirmed the final transfer date, the transfer may arrive after the dry run, which would leave safety laboratory outputs unverified at database lock.

For each risk add a leading indicator (what you would see first), a trigger date and a response. Everything else in the register exists to support those three.

4. Score to decide, not to decorate

A simple three-level scale for likelihood and impact is enough to sort. Add two things that scores omit: proximity (days until impact) and response window (how long you still have to act). Sort first by what is closest and still actionable. Be cautious with arithmetic on ordinal scores, such as multiplying a 4 by a 3: it creates numbers that look precise and are not, and well-known critiques show such scoring can mislead.^[1] Write the scale definitions down, and use the scores to start a conversation, not to end one.

5. Choose a response, and put it in the plan

A response is one of: avoid (change the plan so the risk cannot occur), reduce (lower likelihood or consequence), transfer or share (move part of it to someone better placed) or accept (decide to live with it). These follow the treatment logic in the international risk standard.^[2] Two rules keep this honest. Every mitigation becomes a dated action in the plan with an owner, not a sentence in a register. Every acceptance has a named owner and an expiry date, after which it is reconsidered.

6. Set an escalation ladder with triggers in advance

Triggers fall into four types: time (past the latest acceptable date), impact (milestone or result at stake), ownership (nobody will own it after two days) and quality (a finding that could change a reported result). The response times shown are examples for illustration; set your own and write them where the team can see them.

7. Escalate the decision, not the problem

An escalation is useful when it hands someone a decision they can make. A short brief is enough:

Situation:       One sentence, plus the milestone it affects.
Options:         Two or three, each with cost, time and risk.
Recommendation:  The option you would choose, and why.
Decision needed: By whom, by when.
If no decision:  What happens, and on which date.

Escalating early with options is safe only where raising a problem is safe. Teams that learn that bad news is punished stop raising it, so how the receiver of an escalation responds is part of the method.^[3]

8. Run a 15-minute weekly review

Review only what is changed, new or ageing, starting with items closest to impact. For each: is the date still true, is the response on track, did a trigger fire, can it be closed with evidence? Close items with evidence rather than silence. Useful signals are the number of dependencies past their latest acceptable date, the age of the oldest open risk, and how many escalations received a decision inside their response time. Treat them as conversation starters, not targets.

9. Use the tools where they fit

The Navigator builds a plan from milestone, role and risk context. Workspace holds the dated actions with owners and soft gates between dependent steps, so a slipping dependency is visible where the work is tracked. Readiness Intelligence maps a signal such as a late data transfer to affected artifacts and owners. The Scenario Simulator tests whether a proposed recovery can work at all. Plan buffers, as described for critical chains, belong to the plan as a whole, not to individual tasks.^[4]

A realistic example

Continuing the fictional ZEPHYR-101 study from the lock chapter: lock is Friday 30 October, and on Monday 12 October the programming lead reviews three items at once.

The latest acceptable dates come from the same chain arithmetic as the lock chapter. For X-01: reconcile 2 + rerun priority safety outputs 2 + independent QC 1 + buffer 1 = 6 working days back from Friday 30 October gives Thursday 22 October. The vendor's "end of week" is Friday 23 October, one day past the latest acceptable date, so X-01 is already a risk with eight working days left to act. "Working days left" counts from Monday 12 October to each date.

Ordering. By proximity and response window, X-03 (5 working days) and X-02 (6) come before X-01 (8), even though X-01 is the one the team is talking about most. The register is re-sorted by that, not by colour.

Escalating X-02. On Tuesday 20 October the item is still open, which is the trigger, so the programming lead sends this to the study statistician and the clinical lead:

Situation:       The population rule for major protocol deviations (D-03) is
                 unresolved. Today, Tue 20 Oct, is its latest acceptable date for
                 a Fri 30 Oct lock.
Options:         1. Decide by end of day today. Lock date holds.
                 2. Lock with the current rule; document the alternative as a
                    pre-specified sensitivity analysis. Lock date holds.
                 3. Decide by Fri 23 Oct. Lock moves to Wed 4 Nov.
Recommendation:  Option 2, because it keeps independent QC intact and the
                 alternative is still tested afterwards.
Decision needed: Study statistician and clinical lead, by 16:00 today.
If no decision:  Option 3 applies automatically and lock is re-planned for 4 Nov.

Closing the loop. The decision is recorded against X-02, the mitigation for X-03 appears as a dated action in the plan, X-01 gets a vendor-confirmed date or moves to Level 1 on Thursday, and each closed item points to its evidence.

Common failure modes

Recommended actions

1. Separate your current list into dependencies, risks and issues. Move any item that has already happened into the issues list with an owner.
2. For every dependency, record provider, receiver, need-by date and latest acceptable date, and get the provider to acknowledge it.
3. Rewrite your top five risks as cause, event and consequence, each with a leading indicator and a trigger date.
4. Agree an escalation ladder with your study team: levels, triggers and response times. Put it where everyone can see it.
5. Adopt the escalation brief as the standard format and send the next escalation in that form.
6. Put every mitigation in the plan as a dated action with an owner.
7. Hold the 15-minute weekly review for four weeks and then check whether items are being closed with evidence.
8. Review accepted risks monthly, and drop any whose expiry date has passed.

Good clinical practice asks for risk-proportionate approaches to quality, which in practice means directing review and escalation effort to the things that could change a result or a participant's safety.^[5]

Suggested citation: Shiva Kumar. 2026. “Dependency, Risk and Escalation Management”, in Clinical Statistical Programming Operations: A Practical Leadership Handbook, working edition 0.1. Clinical Data Readiness Navigator. Accessed [date].