The operational problem
Most capacity plans for programming work have the same shape: count the deliverables, multiply by hours each, divide by the people available, and read off a number of weeks. The arithmetic is fine. The inputs are where plans fail.
- A single number hides the spread. Effort per deliverable is skewed: a few outputs take much longer than expected, and almost none take much less. The total of the "most likely" values therefore sits below the realistic middle of the total.
- QC and review are real work. Independent QC cannot be done by the person who wrote the program, so it consumes capacity from someone else and cannot be fully compressed.
- People are not capacity. Capacity is people multiplied by the hours they can actually put into this study, and adding people raises it by less than the headcount suggests.[1]
- Change is the largest variable. A late change to the SAP, a shell or a population reopens work that was already verified.
- People forecast their own work optimistically, even when they know how similar work went before.[2, 3]
- A fully loaded team has no slack, and work waiting for a person to become free grows quickly as utilization approaches 100%.[4]
For a sponsor team or a functional service provider the consequence is the same. If the commitment is a single date, then somebody is carrying a risk that nobody has stated.
Practical methodology
1. Count demand by what drives effort
Count deliverables by category (SDTM datasets, ADaM datasets, tables and listings, figures) and by complexity tier. Write the tier definitions down so that two leads would tier the same output the same way.
| Tier | ADaM dataset | Table or listing |
|---|---|---|
| Simple | Direct mapping from SDTM with few derivations | Single population, descriptive summary |
| Moderate | Several derivations, visit windowing, baseline logic | Subgroups, shift tables, repeated measures summary |
| Complex | Time-to-event with censoring rules, multi-step derivations or cross-dataset dependencies | Model-based output, multiple analysis sets or interim logic |
2. Estimate each tier as a range
For each category and tier, record three values: low, most likely and high hours of production effort. Use your own completed work to set them: the 10th, 50th and 90th percentile of recorded actuals is a sound start once you have about five or more completed units per cell. Do not borrow numbers from elsewhere, and treat any default numbers as placeholders until calibrated.
3. Add the work that is always forgotten
Total effort = production × (1 + QC share + review share) + fixed overhead
- Independent QC share: the independent program, comparison and resolution of differences.
- Review and revision share: statistical and lead review, and the changes that follow.
- Fixed overhead: setup, meetings, tool validation and the dry runs you already know about.
4. Treat change as an input, with triggers
Set a change-risk level (low, medium or high) that stretches the ranges, and write down what counts as a change order: outputs or datasets added beyond the counts, a SAP or shell revision after specification approval, an additional dry run, data that arrives after the agreed cutoff, a standards-version change. Exclusions belong in the plan, not in a conversation later.
5. Convert hours to weeks with honest capacity
Weekly capacity = effective FTE × productive hours per person per week, where
effective FTE = 1 + (people − 1) × parallel efficiency
The parallel-efficiency factor (the Capacity Estimator defaults to 0.8) reflects coordination cost: the fifth person adds less than a full person's worth of output. Productive hours per week are lower than contracted hours once meetings, training and context switching are removed. Account separately for people who join late, who need time to become productive, and for anyone shared across studies.
6. Read the answer as a probability
Compare total effort with capacity over your target window. The result is a probability of meeting the target, not a yes or a no. A useful convention is to commit externally to a date you can reach with about 80% probability, and to run the work internally to the median with the buffer visible. Show the P50, P80 and P90 side by side so that the people deciding can see the spread.[5]
7. Recalibrate every study
Record actual hours by category and tier when work is done. Compare with the estimate, and update the ranges. A team that does this for three or four studies stops needing borrowed numbers.
8. Know what staffing cannot fix
Some of the schedule is waiting, not work: decisions, external data, review windows and sign-off. Adding programmers does not shorten these. Independent QC also sets a floor. The Scenario Simulator is built to show which part of a plan more people can help and which part they cannot.
A realistic example
A fictional study, ZEPHYR-101, needs 77 deliverable units. All numbers below come from the Capacity Estimator using its illustrative default parameters, seed 20260101 and 4,000 draws, so you can reproduce them exactly. The default hours are placeholders, not benchmarks: your calibrated ranges will differ, and the method is what matters here.
| Category | Simple | Moderate | Complex | Units |
|---|---|---|---|---|
| SDTM datasets | 5 | 6 | 1 | 12 |
| ADaM datasets | 1 | 3 | 2 | 6 |
| Tables and listings | 20 | 25 | 8 | 53 |
| Figures | 2 | 3 | 1 | 6 |
| Total | 77 |
Other settings: change risk medium, team maturity mixed, fixed overhead 120 hours, team 4 FTE.
The naive answer. The sum of the most-likely production hours is 1,081. Adding QC at 50% and review at 20% gives 1,838, plus 120 fixed hours is 1,958 hours. Four people have an effective 3.4 FTE (1 + 3 x 0.8) at 30 productive hours a week each, which is 102 hours a week, so the naive plan says 19.2 weeks.
The range.
| Percentile | Total hours | Weeks at 4 FTE |
|---|---|---|
| P10 (optimistic) | 1,953 | 19.1 |
| P50 (median) | 2,352 | 23.1 |
| P80 | 2,643 | 25.9 |
| P90 | 2,801 | 27.5 |
The naive answer (1,958 hours, 19.2 weeks) is almost exactly the P10 outcome: a plan with roughly a one-in-ten chance of being met. The median is about four weeks and 20% more effort than the naive figure, because the real distribution is skewed and the naive plan used the most-likely value of every unit. Moderate tables and listings (21% of production effort), moderate SDTM datasets (14%), complex tables and listings (14%) and complex ADaM datasets (12%) drive most of the spread.
The decision. Suppose the commitment is 22 weeks.
| Option | Probability of 22 weeks | Notes |
|---|---|---|
| 4 FTE, medium change risk | 38% | Median is 23.1 weeks: this is a bet |
| 5 FTE, medium change risk | 89% | The fifth person cuts the median from 23.1 to 18.7 weeks (scaling by headcount alone would say 18.5) |
| 5 FTE, high change risk | 61% | P80 rises to 24.1 weeks |
| 4 FTE, commit to 26 weeks instead | 81% | A defensible commitment without extra staff |
The real choice is not "4 or 5 people". It is which probability the organization is willing to accept for which commitment. A leader might commit to 26 weeks with the current team (81%), or request a fifth programmer for 22 weeks (89% while change stays medium), and agree in writing that a high-change scenario triggers a change order, because the same fifth person then yields only 61%.
Common failure modes
| Failure mode | How it shows up | Countermeasure |
|---|---|---|
| Single-number estimates | One date, no stated probability | Report P50, P80 and the probability of the target |
| QC and review assumed free | The plan has production hours only | Add explicit QC and review shares (method 3) |
| Counting headcount, not capacity | Six names on the plan, three people's output | Effective FTE and productive hours (method 5) |
| Planning at full utilization | Any change creates a queue | Keep deliberate slack; plan to P80 for commitments |
| Late joiners treated as immediate | Plan assumes day-one productivity | Model ramp-up; use the Simulator |
| Split allocation hidden | A person counted at 1/3 on three studies, with no switching cost | Count shared people at less than their share; state the assumption |
| Undefined complexity tiers | The same output estimated two ways by two leads | Written tier definitions (method 1) |
| Estimates never compared to actuals | The same optimism every study | Record actuals and recalibrate (method 7) |
| No change-order triggers | Scope growth absorbed silently | Write triggers and exclusions into the plan (method 4) |
| The plan is read as a promise | A forecast becomes a commitment nobody can discuss | State the probability and what would move it |
Recommended actions
- Define your tiers. Write one-paragraph definitions for simple, moderate and complex by category and get them agreed across leads.
- Start recording actuals by category and tier for the work being done now, even in a spreadsheet. About five completed units per cell is enough to begin calibrating.
- Plan with ranges in the next proposal or allocation, and quote the probability of the target date.
- Choose a commitment rule, for example commit at about P80 and run to P50 with the buffer visible, and apply it consistently.
- List your exclusions and change-order triggers in the plan itself and agree them with the other party before work starts.
- Name your slack. Decide how much unplanned capacity you keep for change and absence, and protect it.
- Test recovery options in the Scenario Simulator before promising that "more people" will fix a compressed timeline.
- Review after each study: compare estimate with actuals, update the ranges, and keep the assumptions log with the plan.
Good clinical practice emphasizes quality management that is fit for purpose and proportionate to risk, and a plan that states its assumptions and risks is easier to defend on that basis.[6]
Template
Capacity plan and assumptions log
One table for demand lines, supply lines, assumptions, exclusions and change-order triggers. Example rows reproduce the worked example in this chapter.
| Line type | Item | Quantity | Low hours | Likely hours |
|---|---|---|---|---|
| Demand | SDTM datasets, simple | 5 | 8 | 12 |
| Demand | SDTM datasets, moderate | 6 | 16 | 24 |
| Demand | SDTM datasets, complex | 1 | 30 | 45 |
| Demand | ADaM datasets, simple | 1 | 10 | 16 |
| Demand | ADaM datasets, moderate | 3 | 20 | 32 |
| Demand | ADaM datasets, complex | 2 | 40 | 64 |
Preview of the first 5 of 13 columns and 6 synthetic example rows. The download has all 13 columns, blank rows with formulas, and no study data.
Apply it
Apply it in the Navigator
The Handbook explains why and how to decide. The Navigator turns the same logic into dated, owned actions for your milestone, in your browser, with no study data.
- Open the Capacity EstimatorEffort as a P10 to P90 range, with QC and review included
- Test staffing recoverySee what extra people can and cannot fix
Supporting references
References
- Brooks FP. The Mythical Man-Month: Essays on Software Engineering. Anniversary ed. Addison-Wesley; 1995.
- Buehler R, Griffin D, Ross M. Exploring the "planning fallacy": why people underestimate their task completion times. Journal of Personality and Social Psychology. 1994;67(3):366-381.
- Kahneman D, Tversky A. Intuitive prediction: biases and corrective procedures. TIMS Studies in Management Science. 1979;12:313-327.
- Reinertsen DG. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing; 2009.
- Goldratt EM. Critical Chain. North River Press; 1997.
- ICH. E6(R3) Guideline for Good Clinical Practice. International Council for Harmonisation; 2025. www.ich.org ↗
Links go to the publisher's page. Standards and guidance change: confirm the version in force for your study, sponsor and region before relying on any reference. The worked examples are synthetic and illustrative; they are not benchmarks.
Review status
This chapter has not yet been independently reviewed
It is an author draft written from statistical programming leadership practice. No practitioner has reviewed it yet, and nothing here should be read as validated or endorsed by anyone else. If you work in this area, a 45-minute review using a synthetic scenario is the most useful thing you can do for it.
Suggested citation: Shiva Kumar. 2026. “Resource and Capacity Planning”, in Clinical Statistical Programming Operations: A Practical Leadership Handbook, working edition 0.1. Clinical Data Readiness Navigator. Accessed [date].