The Power of the Right Question: How Requirements Elicitation Transforms Project Outcomes in Biotech and Pharma
- Jordan Webb
- Mar 17
- 6 min read
Introduction
Most biotech and pharma project failures don't begin when timelines slip or budgets blow. They begin in the first planning meeting, when the wrong questions were asked — or no questions were asked at all. In an industry defined by high-stakes investments and unforgiving regulatory timelines, that distinction matters enormously. IQVIA's 2025 Global Trends in R&D report found that total program duration from Phase I start to regulatory approval now averages 9.3 years, (link) and biopharma's internal rate of return for R&D investment has fallen to 4.1% — well below the cost of capital. (link) There is simply no margin left to absorb the cost of scope gaps that were discoverable at project initiation.
The Tufts Center for the Study of Drug Development found that 76% of clinical trial protocols now require at least one substantial amendment, with the mean number of amendments per protocol increasing 60% to 3.3, and the average time to implement a single amendment reaching 260 days — nearly triple what it was a decade ago. (link) Many of those amendments trace back not to scientific uncertainty, but to a requirements failure: a need that was discoverable at initiation and simply wasn't documented. The Project Management Body of Knowledge (PMBOK) Guide frames the Collect Requirements process as a core Planning discipline, not an informal conversation — structured, stakeholder-driven, and completed before scope is defined. This post explains what that discipline looks like in a life sciences context and what it costs when it's skipped.
The High Cost of Poorly Defined Requirements in Drug Development
Tufts CSDD analyzed 836 protocols and found that 57% required at least one substantial amendment, with nearly half — 45% — of those amendments deemed avoidable. The median direct cost to implement a substantial amendment was $141,000 for a Phase II protocol and $535,000 for a Phase III protocol. (link) Avoidable amendments are not scientific surprises. They are scope changes caused by requirements that were knowable before the protocol was locked — poorly defined inclusion and exclusion criteria, endpoints that weren't pressure-tested against site feasibility, visit schedules that didn't account for patient burden. Tufts CSDD identified that one-third of all amendments were partially or completely avoidable, with undetected design flaws and difficulties recruiting study volunteers cited as causes sponsors could have better anticipated during planning. (link)
The broader industry context makes this more urgent, not less. PPD and Thermo Fisher's 2024 global survey of drug developers found that 49% identified rising costs as the top challenge, with patient recruitment cited by 39% — both directly affected by protocol design quality and requirements clarity at initiation. (link) Scientific uncertainty will always drive some changes, and that is expected. The goal of disciplined requirements elicitation is not to eliminate all change, but to ensure that the changes that do happen are driven by science, not by planning gaps that should never have existed.
PMBOK: Collect Requirements Is a Planning Discipline, Not a Meeting
The PMBOK defines requirements as the conditions or capabilities that must be present in a product, service, or result to satisfy an agreement or other formally imposed specification. Collect Requirements belongs explicitly within the Planning performance domain — it precedes scope definition by design, because scope that is defined without complete requirements is scope that will change. The process produces two key outputs: requirements documentation, which is the written record of stakeholder needs and constraints, and the Requirements Traceability Matrix (RTM), which links each requirement to its originating objective and tracks it through execution to confirmed delivery.
A critical distinction the PMBOK draws is that requirements span multiple categories: business requirements (why the project exists), stakeholder requirements (what each function needs from the outcome), solution requirements (the specific capabilities that must be delivered), and transition requirements (what must be in place for the deliverable to move into operations). In drug development, these map directly to scientific and clinical objectives, regulatory pathway obligations, GxP operational constraints, and system or technology handoff requirements — and all four must be represented before scope is baselined. The "need more information" conclusion to a planning meeting is not a neutral outcome. Ambiguity accepted at initiation becomes a scope change, a budget variance, or a protocol amendment — typically at the worst possible moment in the project lifecycle. Research consistently shows that many avoidable amendments stem from insufficient stakeholder input and inadequate planning, and that better upfront protocol work saves substantial time and money. (link)
Asking Better Questions: Frameworks for Biotech PMs
Requirements elicitation in biotech and pharma is complicated by the fact that every major stakeholder group — scientists, clinicians, regulatory affairs, commercial, and finance — approaches the project from a different framework and describes needs in a different professional language. Scientists are often comfortable with ambiguity and may resist locking requirements because flexibility feels like scientific rigor. Clinicians surface requirements as operational concerns rather than formal statements. Regulatory affairs professionals hold requirements embedded in ICH guidelines and prior agency feedback letters that must be proactively extracted. Commercial teams frequently arrive late to early-stage conversations, and when their requirements surface mid-program, they look exactly like scope change. The PMBOK is explicit that stakeholder engagement is a continuous process — but the first requirements conversation is the most consequential, and it must cover all domains.
Three question frameworks are especially useful for structuring that work. The 5 Whys surfaces the real requirement beneath the stated solution — a team that says "we need more investigative sites" is presenting a solution; asking why repeatedly reveals the underlying requirement: define inclusion and exclusion criteria that are clinically defensible and operationally feasible for available patient populations. MoSCoW prioritization forces stakeholders to categorize requirements as Must Have, Should Have, Could Have, or Won't Have, which directly addresses one of the most common cost drivers in early-stage trials — what might be called "scope creep by scientific curiosity," the mid-program accumulation of additional endpoints and exploratory objectives that individually seem minor but collectively derail timelines. Portions of the INVEST criteria — originally from software development but directly applicable to work package validation — ensures that each requirement accepted into scope is Valuable (linked to a named objective), Estimable (resourceable with reasonable confidence), and Testable (accompanied by a defined acceptance criterion). A requirement that fails Estimable or Testable is not ready to become a scope item.
The Requirements Traceability Matrix: Making Requirements Work for the Full Project Lifecycle
The RTM links each requirement to its originating source — regulatory obligation, business objective, stakeholder input, or scientific requirement — tracks it through project execution, and confirms delivery at closeout. The PMBOK identifies it as a direct output of Collect Requirements and positions it as the connective tissue between requirements management, scope management, change control, and project closure. Despite this, it remains one of the most consistently underused tools in biotech project management, often dismissed as an IT artifact or administrative overhead.
The overhead objection deserves a direct response: organizations that believe they cannot afford an RTM are precisely the organizations paying $535,000 per Phase III protocol amendment. A biotech-appropriate RTM does not need to be complex. A well-structured document should capture, for each requirement, a unique identifier and description, its originating source, a MoSCoW priority, the linked WBS element, current status, and a change history. That change history is where the RTM earns its keep as a change control tool — when a scope change request arrives, the project manager should be able to answer immediately which requirement it serves or introduces, making the conversation factual rather than political. In GxP environments, the RTM also supports audit readiness by documenting why specific activities were included in scope, providing traceability that regulators increasingly expect. For most biotech programs, a well-maintained Excel or SharePoint-based RTM, reviewed at each stage gate, is entirely sufficient.
Before closing any requirements session, three outputs must exist:
Documented requirements, not action items — every requirement must be written down, assigned to a source, and given a priority; a verbal understanding is a scope gap waiting to emerge
Stakeholder agreement, not just discussion — unresolved requirements must be escalated before scope is baselined; they are future scope changes with deferred price tags
Explicit prioritization — a complete requirements document is one where every item has a priority, so scope trade-offs can be made deliberately rather than reactively when constraints tighten
Conclusion
With biopharma R&D returns at 4.1% and the Phase I success rate down to 6.7%, (link) the industry has no margin for requirements that could have been documented at initiation. Protocol amendments, scope creep, budget overruns, and stakeholder misalignment are not inevitable features of drug development — many are the delayed costs of planning gaps that structured elicitation, deliberate stakeholder engagement, and a maintained RTM could have surfaced and resolved before a single deliverable was executed. The project manager who invests in asking better questions at the start isn't doing extra work. They're doing the highest-leverage work available before the clock starts. At Ganvion Biotech Solutions, we help biotech and pharma teams build requirements-driven project plans from initiation — so that the questions nobody thought to ask don't become the budget variances explained at the next board meeting.