ACRP-PM study materials
ACRP-PM study resources

The Steering Committee Wants the Date, Not the Range

ACRP-PM · Put your knowledge to work in context.

All case studies

The Steering Committee Wants the Date, Not the Range

You are PM for a 14-site, 480-subject Phase 3 study. At the last steering committee, the executive sponsor asked for "the database lock date" and you gave a single date: 14 November. That date was built from a bottom-up schedule with three critical-path dependencies: last patient last visit (LPLV) on 30 September, a 4-week clean-patient-data period, and a 3-week statistical analysis. Since then: the LPLV forecast has slipped 3 weeks because one site is behind; the data management vendor has flagged that queries per subject are running 40% above plan; and the biostatistician has said the 3-week analysis assumed a clean dataset, which the query volume now makes unlikely. The steering committee meets again in 5 days and the sponsor has already told the board "database lock in November."

1. How do you present the schedule at the next steering committee, and what do you do in the 5 days before it?

Read the worked answer

In the 5 days: rebuild the forecast as a range with explicit drivers, not a new single date. A new single date just resets the same trap.

  1. Re-forecast LPLV by site. Don't apply the 3-week slip as a flat number - model the lagging site's realistic completion based on its current rate, and check whether the other 13 sites' LPLV dates move the critical path at all. Often only one or two sites actually drive the date.
  2. Quantify the query load. 40% above plan is only meaningful if you translate it: how many queries, how many FTEs clearing them, what's the observed clearance rate, and therefore how many weeks to clean? Get this from the DM vendor in writing, with their assumptions.
  3. Re-sequence the analysis assumption. The biostatistician's caveat is the most important input: if analysis can't start until data are clean, the 3-week analysis is additive to a longer cleaning period, not overlapping it. Ask whether any analysis steps (e.g., TLF programming on mock data, dry runs) can run in parallel so the post-clean analysis window shrinks. That's a real schedule lever, not optimism.
  4. Build three scenarios - best case (lagging site recovers, queries clear at plan rate), likely case (partial recovery, query clearance at observed rate), worst case (site doesn't recover, query backlog persists). Give each a date and state the assumptions that separate them.

At the meeting: lead with the decision, not the data. "The 14 November date is no longer defensible. Here is a range of [X] to [Y], here is what drives the difference, and here are the two decisions I need from you to hold the earlier end." Present the range visually with the drivers labeled. Name the specific decisions - e.g., authorize additional data-management capacity to clear queries, and/or approve a protocol-defined approach to the lagging site.

Do not bury the sponsor's board statement. Address it directly: "You told the board November. Based on what we now know, November is at risk; I want to give you the corrected picture before the next board update, not after." A PM who lets a known-wrong date stand because it was already said publicly is the one who owns the surprise.

2. The sponsor says: "Just give me one date. I can't take a range to the board." What do you say, and what do you actually give them?

Read the worked answer

Give them one date - but make it the right one and attach the condition.

The sponsor's real need is a number they can commit to publicly without being embarrassed. A range feels like hedging because it doesn't answer "what do I say?" So answer that question: "Commit to [the likely-case date]. It has roughly [X]% confidence given current information, and here are the two things that would move it earlier or later."

Why the likely case rather than the best case: a public commitment should be a date you expect to hit, not a date you hope to hit. Committing to the best case converts every normal variance into a broken promise. Committing to the likely case gives you a defensible plan and upside if things go well.

What to hand over:

  • One date, stated plainly.
  • The confidence level and the two or three assumptions it rests on.
  • The early-warning triggers: "If the lagging site hasn't reached [N] subjects by [date], or query clearance is below [rate] by [date], I will tell you within a week that the date is moving." This is the part that makes a single date honest - it's not a promise that nothing will change, it's a promise that they'll hear it from you first.
  • A one-page backup they can keep, not present, so the range exists without being the headline.

The principle: the sponsor is asking you to solve a communication problem, not to lie about the schedule. Refusing to give a single date is technically rigorous and practically unhelpful - it pushes them to invent their own number. Give them a date you can defend, with the conditions attached, and make the early-warning commitment explicit so the next conversation is a heads-up rather than a surprise.