Workload & Capacity Planning: From Volume to FTEs

Why this matters

Under‑staffing is the quiet killer of database lock timelines. If you model the work honestly, you can secure temporary full‑time equivalents (FTEs) early and avoid last‑minute chaos.

Plain‑English glossary used here

• FTE — Full‑Time Equivalent (the amount of work one full‑time person can deliver in a period).
• CRF — Case Report Form (the electronic forms sites complete in EDC).
• EDC — Electronic Data Capture system.
• DSMB — Data and Safety Monitoring Board, also called a Data Monitoring Committee (DMC): reviews accumulating study data at set points while the study runs; each data cut needs current data with the critical fields (safety first) cleaned by the cut date.
• LPLV — Last Patient Last Visit (often triggers a data surge).
• Burndown — The planned weekly fall in open work (e.g., queries, uncoded terms) to zero by a date (lock or a DSMB cut), tracked against actuals.

Core concepts & quick formula

• The quick way to size FTEs

  1. Count the work items in the period: volume × frequency (e.g., 150 files per weekly transfer × 4.33 transfers a month (52 ÷ 12) = 650 files a month).
  2. Multiply by minutes per item (measured from your historicals or pilots).
  3. Divide the total minutes by the productive minutes one FTE has in that period. Tip: “Productive time” excludes meetings, administration, training and leave. Many teams plan ~30 productive hours per week per FTE. By month: FTE = (volume × frequency × minutes per item) ÷ (hours per FTE‑month × 60). At 12 minutes a file, 650 files = 7,800 minutes = 130 hours: 1.0 FTE at 30 productive hours a week (30 × 4.33 = 130 hours a month), but about 0.8 FTE on a nominal 160‑hour FTE‑month, which still counts meetings, training and leave. Use the basis your plan sets and say which one you used; a nominal basis understates the need (see Pitfalls).

• Plan for peaks, not averages Average monthly volume hides spikes (LPLV and end‑of‑study clean‑up, DSMB data cuts, vendor batch loads). Staff to the peak weeks.

• Owner split Keep separate capacity lines for site‑owned work (e.g., CRF entry, query responses) vs vendor‑owned or DM‑owned work (e.g., coding, reconciliation). You cannot staff what you can’t see. DM does not take on site‑owned work: it tracks it and escalates slippage for CRA follow‑up, because site staff own entry and correction of site data (DM raises queries, never edits).

• Buffers are intentional Add small buffers (e.g., +15–30%; more for known near‑lock spikes, such as +40% in Example A) where variability is high (device uploads, lab merges).

• Tie to outcomes Your FTE plan should map directly to the burndown curve for lock or DSMB data cuts.

Planning flow, step‑by‑step

1. Map the streams of work Examples: CRF review, query writing/closure, medical coding, SAE reconciliation, device/ECG file processing, adjudication packet assembly.

2. Quantify each stream weekly Use: volume × frequency × minutes per item. Note vendor cadence (e.g., labs weekly, ePRO twice weekly). Identify surges (late site adds, recruitment campaigns, end‑of‑study housekeeping).

3. Convert to FTEs Sum minutes per week per stream → divide by productive minutes per FTE per week. Round up for surge weeks.

4. Plan capacity

   • Internal: temporary FTEs, borrowing from other studies, pre‑approved overtime windows. Allow lead time: new or borrowed staff complete study training before they get their own EDC account, with only the role they need.
   • Vendor: surge riders in the Statement of Work (SOW), call‑off hours (extra hours drawn on request at agreed rates), defined turnaround time (TAT) commitments; agree them up front, since work outside the SOW needs a change order.

5. Link to burndowns Set weekly targets (e.g., reduce open queries from 2,400 → 0 in 6 weeks: a net fall of 400 a week, after new queries). Re‑forecast every 2 weeks. If off‑track, trigger escalation. Example: at week 2 the target is 1,600 open but 1,900 remain, so the last 4 weeks need 475 a week; find whose work is behind and act by owner. Queries waiting for site answers are escalated per the DMP for CRA follow‑up with the site (through CRO DM in a CRO‑run study), vendor backlogs go up the vendor’s contract line and draw on its pre‑agreed surge hours, and pre‑approved temporary FTEs take DM‑owned work such as query review and closure.

6. Close the loop After the surge, taper capacity, document actuals vs plan, and update your minutes‑per‑item benchmarks.

What good looks like

• A one‑page weekly table showing FTE needed vs staffed by stream, with a simple green/amber/red status.
• Clear owner segmentation (site, vendor, internal DM) and named owners for each stream.
• Contingency: pre‑approved vendor surge hours, internal float pool, and an overtime policy window tied to specific dates.
• Burndown linkage: the table includes weekly targets and shows whether each stream is on pace for lock or DSMB cut.

Mini example table (illustrative)

Decision this week: add 0.7 FTE to CRF review from the pre‑approved, already‑trained float pool, or risk burndown slip.

Worked examples (CV trial)

Assumptions and math are shown so you can adapt them to your study. Replace with your own measured minutes per item.

Example A — Device data stream (steady‑state with a lock buffer)

• Context: Cardiovascular (CV) device files arrive weekly from a vendor.
• Inputs (weekly): 320 files; 5 minutes per file to ingest, QC, and reconcile; 30 productive hours per FTE per week.
• Work minutes: 320 × 5 = 1,600 minutes → 26.7 hours per week.
• Baseline FTE needed: 26.7 ÷ 30 ≈ 0.9 FTE (sustained over 26 weeks).
• Near‑lock buffer: Expect ~40% extra reconciliation and re‑pulls for 3 weeks → +10.7 hours/week. Extra FTE for buffer: 10.7 ÷ 30 ≈ 0.36 FTE → staff +0.4 FTE (rounded up) during those 3 weeks.
• Cadence check: if the vendor sent one monthly batch instead (about 1,390 files: 320 × 4.33), that week would bring about 116 hours of work, or 3.9 FTE; keep the weekly cadence in the SOW, or plan surge capacity for batch weeks.

Takeaway: Budget ~0.9 FTE steady‑state for the stream, plus 0.4 FTE for the 3‑week lock window.

Example B — Late site additions create an end‑game surge

• Context: 12 sites activated in Month 10; data hits near LPLV over an 8‑week window. Goal: keep median query age ≤14 days.

• Assumptions:

  • 12 sites × 8 participants each = 96 participants contributing data in the window.
  • Each participant completes 2 visits in the window; 18 CRF pages per visit; 3 minutes per page for review.
  • Query rate: 0.6 queries per page; 3.5 minutes per query to write/close.
  • Coding: 7 terms per participant at 1.5 minutes each.
  • Backlog clean‑up: additional 10 pages per participant at 3 minutes each.
  • Productive time: 30 hours per FTE per week.

• Compute hours (for the whole 8‑week window):

  • CRF review = 96 × 2 × 18 × 3 min = 10,368 min = 172.8 h
  • Query write/close = 96 × 2 × 18 × 0.6 × 3.5 min = 7,257.6 min = 121.0 h
  • Coding = 96 × 7 × 1.5 min = 1,008 min = 16.8 h
  • Backlog clean‑up = 96 × 10 × 3 min = 2,880 min = 48.0 h
  • Total = 358.6 h over 8 weeks → 44.8 h/week

• FTE needed for the surge window: 44.8 ÷ 30 ≈ 1.5 FTE for 8 weeks.

Takeaway: Pre‑approve +1.5 temporary FTE for 8 weeks to protect query aging and lock.

Pitfalls & misconceptions

• “Averages will carry us.” False. Peaks determine outcomes, especially around DSMB cuts and LPLV.
• Mixed ownership. Blending site, vendor, and internal DM tasks into one number hides gaps. Segment owners.
• Too late to surge. Waiting until metrics are red means you are already in a hole; surge capacity should be pre‑approved.
• Wishful productivity. Planning on 40 productive hours per week ignores meetings, training, PTO. Size to real productive time.
• Static plans. Capacity plans are living documents. Re‑forecast every 2 weeks; update minutes‑per‑item from actuals.

Practice in the wild (checklist)

• Build a weekly FTE plan per stream (CRF, queries, coding, reconciliation), including buffers.
• Forecast surge weeks (late site adds, vendor batch cycles, interim analyses).
• Put surge clauses in SOWs (call‑off hours, TAT) and pre‑approve temporary FTEs.
• Link plan to escalation triggers: • % queries >14 days, • backlog trend 3 weeks ↑, • coding queue above its agreed limit, • reconciliation defects above the agreed weekly limit.
• Review capacity vs burndown weekly; re‑forecast every 2 weeks.
• After lock, taper capacity and record actual minutes‑per‑item for future studies.

Key points to remember

• Convert workload to FTEs using volume × frequency × minutes per item ÷ productive minutes per FTE for the period; size to productive time (e.g., ~30 h/week), not calendar hours, and staff to peaks, not averages.
• Keep owner‑segmented capacity lines (site, vendor, internal DM) so gaps are visible and accountable.
• Tie capacity directly to burndown targets for lock/DSMB cuts; set weekly goals and escalate early when off‑pace.
• Translate vendor batch streams (device, ePRO, labs) into staffing with a minutes‑per‑file model; add a near‑lock buffer where variability is high (~15–40%).
• Re‑forecast every 2 weeks; watch guardrails (e.g., median query age ≤14 days, coding queue size, reconciliation defects) and trigger surge plans before metrics go red.
• Choose the right lever for gaps—pre‑approved temporary FTEs, vendor surge hours/call‑offs, or limited overtime windows—based on ownership, turnaround time, and cost; site‑owned gaps are escalated for CRA follow‑up, not staffed by DM.
• Anticipate late‑site additions and end‑game spikes (LPLV, interim analyses); pre‑approve temporary capacity blocks sized to the surge window (8 weeks in Example B) to protect query aging and lock.
• Use a one‑page weekly table (needed vs staffed, by stream) with green/amber/red status to drive decisions; round up for surge weeks.
• After surges, taper capacity and capture actual minutes‑per‑item to refine future plans.