Chapter 10 / Managing the Clinical Trial Lifecycle / Free sample chapter
Chapter 10: From Product Strategy to Protocol Concept
How product strategy becomes an executable protocol concept without hiding assumptions.
10.1 The Morning After Design Selection
The morning after the DIAB-220 design review, Lauren Brooks arrived with a full notebook and the wrong kind of confidence.
The team had done hard work in Chapter 9. They had moved past the false question, "Which design is best?" and chosen a staged randomized [ICH E9] Phase II dose-ranging study, supported by a separate observational evidence plan. We are returning to the pre-protocol moment, after the design-selection conversation but before the Phase II protocol is drafted. The decision was not perfect. Good decisions rarely are. But it was reasoned, documented, and defensible.
Lauren thought the next step was obvious.
"So now we write the protocol?" she asked.
Maggie Chen smiled in the way experienced operations leaders smile when someone has skipped three invisible steps.
"Not yet," she said. "Now we make sure strategy has become a trial concept. Then we write the protocol."
That distinction matters.
A protocol is the detailed document that describes how a clinical trial will be conducted. A protocol concept is earlier. It is a structured trial idea that translates product strategy into the core choices a protocol will later develop in detail: rationale, objective, population, intervention, comparator, endpoints, design, duration, major assessments, safety approach, feasibility assumptions, and governance decision.
The protocol concept is not a miniature protocol. It is not a marketing wish list. It is not a slide that says "Phase II, randomized [ICH E9], 300 patients, first patient in Q3" and hopes the details will behave.
It is the place where ambition first meets evidence.
In clinical trial project management, a surprising amount of later pain begins here. A vague strategy becomes a vague objective. A vague objective becomes a protocol with too many endpoints. A protocol with too many endpoints becomes a schedule no site can run. A schedule no site can run becomes slow enrollment, missing data, amendments, budget pressure, and a team asking why execution is so difficult.
Sometimes execution is difficult because the execution team failed.
Sometimes execution is difficult because the concept was never honest.
Chapter 10 is about that early honesty.
10.2 Product Strategy Is Not the Protocol
Product strategy is the business, medical, regulatory, and patient-access logic for developing a product. It asks why the product matters, who it is for, what unmet need it may address, how it might be differentiated, what evidence will be needed, and what future decisions the development program must support.
Product strategy includes more than commercial ambition. It may include:
- intended indication, meaning the disease or condition the product is being developed to treat, prevent, diagnose, or manage;
- target population, meaning the patients for whom the product may be appropriate;
- unmet medical need, meaning the gap between current care and what patients, clinicians, regulators, or payers still need;
- value proposition, meaning why the product may matter compared with existing options;
- benefit-risk profile, meaning the expected balance between benefit and harm;
- dose, route, regimen, and treatment setting;
- evidence needed for approval, labeling, medical adoption, access, reimbursement, and lifecycle planning.
A target product profile (TPP) is a strategic development tool that describes the intended future profile of a product, often in language that resembles possible labeling concepts. A good TPP helps a team ask, "What evidence would we need to support this future statement?" It is not a promise of approval. It is not a binding agreement with regulators. It is not a substitute for data.
A clinical development plan (CDP) is the program-level plan that connects the studies and evidence needed across development: clinical pharmacology, dose selection, proof of concept, confirmatory evidence, safety, special populations, regional needs, pediatric planning when applicable, and postmarketing questions.
Lauren wrote three lines on the whiteboard:
Product strategy asks: Where are we trying to go?
Clinical development planning asks: What evidence path gets us there?
Protocol concept asks: What is this next study supposed to prove, learn, or decide?
That last question is where the project manager (PM) becomes essential.
The PM does not own the product strategy alone. Medical, regulatory, statistics, commercial, safety, patient engagement, executive leadership, and other functions all shape it. But the PM often sees when strategy language has not yet become executable.
When this chapter refers to FDA, EMA, and ICH, it means the U.S. Food and Drug Administration, the European Medicines Agency, and the International Council for Harmonisation. The detailed regulatory interactions come later in the book; here, they matter because concept choices should be able to survive informed regulatory discussion.
"Differentiated benefit-risk profile" is strategy language.
"A randomized [ICH E9] Phase II study in adults with type 2 diabetes inadequately controlled on background therapy, comparing three DIAB-220 doses against placebo over twenty-four weeks, with HbA1c, a common measure of average blood glucose over time, as the primary endpoint and structured tolerability monitoring" is concept language.
The first may be true.
The second can be planned.
10.3 The Trial Concept: The Bridge Between Strategy and Operations
A protocol synopsis or concept sheet is a short structured summary used before the full protocol. Companies use different names and formats, but the purpose is similar: make the study idea clear enough for cross-functional review before detailed protocol drafting begins.
For a beginner, the easiest way to understand a protocol concept is this:
It is the bridge between "we need evidence" and "sites will run this."
Too thin a bridge, and the protocol team falls through.
For DIAB-220, Lauren built a first concept sheet from the design decision. It looked tidy:
| Field | DIAB-220 First Draft Concept |
|---|---|
| Development decision | Select dose for later confirmatory development |
| Study type | Randomized [ICH E9] Phase II dose-ranging study |
| Population | Adults with type 2 diabetes and inadequate glycemic control |
| Intervention | DIAB-220 three dose levels |
| Comparator | Placebo added to background therapy |
| Primary endpoint | Change in HbA1c at Week 24 |
| Key secondary endpoints | Weight change, tolerability, adherence, patient-reported burden |
| Duration | 24-week treatment plus follow-up |
| Evidence use | Dose selection, benefit-risk characterization, regulatory discussion |
| Main assumptions | Enrollable population, acceptable rescue rules, feasible visit schedule, reliable endpoint capture |
It was a start.
It was not enough.
Samuel Reeves asked, "Which background therapy? Stable for how long? What rescue medication rules protect patients if glucose worsens?"
Claire Jiang asked, "What treatment effect are we trying to estimate, and what happens if patients discontinue treatment or start rescue therapy?"
Thomas Gallagher asked, "What regulatory conversation is this meant to support, and what questions do we expect regulators to ask about dose, population, and comparator?"
Rafael Ortiz asked, "How many sites can actually find these patients if the background-therapy and HbA1c criteria are narrow?"
Maya Desai asked, "What do three dose arms do to drug supply, monitoring, vendors, and budget?"
Victor Stein asked, "Can the electronic data capture system support the endpoint schedule without creating unnecessary query volume?"
Helen Park asked, "Where will the decision rationale live, and how will version changes be traceable?"
Lauren looked at the table again.
"So a concept sheet is not approval," she said. "It is a way to find out what is not ready to approve."
"Exactly," Daniel Liang said.
10.4 What Decision Must DIAB-220 Make Next?
The most important field in a protocol concept is not the sample size.
It is the decision.
A go/no-go decision is a planned decision about whether to continue, stop, modify, or redirect a program or study based on defined evidence and judgment. Not every decision is literally go or no-go. Some decisions are dose selection, population narrowing, endpoint confirmation, safety characterization, regional strategy, or whether a future confirmatory trial is justified.
DIAB-220 did not need the Phase II study to answer every future question. It needed the study to support the next decision:
Which dose or dose range should move forward, and is the benefit-risk profile strong enough to justify confirmatory development?
That decision shaped everything else.
| Strategic Want | Concept Translation Question |
|---|---|
| Show glycemic benefit | What endpoint and time point best support the dose decision? |
| Understand tolerability | What adverse events and discontinuations must be captured clearly? |
| Preserve future label options | Is the population too narrow, too broad, or appropriate for this stage? |
| Move quickly | Which design elements protect speed without damaging interpretability? |
| Support regulatory discussion | What evidence gaps should be surfaced before agency interaction? |
| Maintain patient trust | What burden and rescue rules make the study acceptable? |
The PM's task is not to make the decision alone.
The PM's task is to stop the team from pretending several different decisions are one decision.
In DIAB-220, one leader wanted dose selection. Another wanted proof of cardiovascular reassurance. Another wanted patient-reported outcomes strong enough for future differentiation. Another wanted broad routine-practice relevance. Those ambitions were not foolish. They were just too heavy for one Phase II concept.
Caroline Whitaker put it well.
"If the governance slide says this trial will select dose, demonstrate differentiation, support future labeling, reassure safety, and prove real-world value, then we are not aligned. We are stacking hopes."
That sentence changed the meeting.
10.5 From Intended Claim to Study Objective
An objective is the question or purpose a study is designed to address. A primary objective is the main question. Secondary objectives address important supporting questions. Exploratory objectives investigate additional signals or hypotheses that may inform future work but are usually not the basis for the main conclusion.
A protocol concept should connect intended claim, objective, endpoint, and design.
It should also expose when the connection is weak.
For DIAB-220, the intended future claim was not final label language. It was a working strategic ambition: DIAB-220 may offer clinically meaningful glycemic improvement with an acceptable tolerability profile in adults whose diabetes is not adequately controlled on existing therapy.
That ambition had to become a study objective:
To evaluate the dose-response, efficacy, safety, and tolerability of DIAB-220 compared with placebo when added to stable background therapy in adults with type 2 diabetes inadequately controlled on current treatment.
Then the objective had to become endpoints.
An endpoint is what the study measures to answer an objective. A primary endpoint is the main outcome used to answer the primary objective. A secondary endpoint supports additional interpretation. An exploratory endpoint may generate hypotheses or context for future studies.
Endpoint hierarchy matters. If a team lists twelve "key" endpoints without hierarchy, it is often avoiding a decision. FDA guidance on multiple endpoints warns, in practical terms, that multiple comparisons can create interpretive problems when many outcomes are tested without adequate control of error.
Claire did not say it as a lecture.
She said, "If everything is key, nothing is protected."
That helped Lauren.
She revised the concept sheet:
The team used the decision log [PMBOK] to turn the details into operating choices the PM could assign, monitor, and escalate:
Primary objective. Better Diab-220 Wording was Evaluate the effect of DIAB-220 dose levels on glycemic control at Week 24.
Primary endpoint. Better Diab-220 Wording was Change from baseline in HbA1c at Week 24.
Secondary objectives. Better Diab-220 Wording was Characterize dose-response, weight change, tolerability, rescue medication use, adherence, and patient-reported burden.
Exploratory objectives. Better Diab-220 Wording was Explore biomarkers and subgroups that may inform later studies.
Decision criterion. Better Diab-220 Wording was Identify dose or dose range with adequate efficacy, tolerability, and feasibility for confirmatory planning.
The wording was still early.
But now the concept had a spine.
10.6 Population, Comparator, Dose, Endpoint: The Four Early Anchors
The protocol concept becomes unstable when four anchors drift apart: population, comparator, dose, and endpoint.
The patient population is the group the study intends to enroll. Eligibility criteria are the inclusion and exclusion rules that determine who can participate. Inclusion criteria describe who may enter; exclusion criteria describe who may not enter. Eligibility criteria are not just administrative filters. They shape safety, recruitment, generalizability, interpretation, and ethics.
A comparator is what the investigational product is compared against. Standard of care means usual accepted care in the relevant clinical setting, though it can vary across countries and sites. A placebo is an inactive treatment designed to resemble the investigational treatment. An active control is an existing active treatment used as the comparator.
A dose regimen describes dose amount, route, frequency, and treatment schedule. A treatment arm is a group assigned to receive a specific intervention or comparator. Randomization means assigning participants by a planned chance-based method. Blinding [ICH E9] or masking means keeping certain people unaware of treatment assignment to reduce bias.
For DIAB-220, the four anchors created real tension:
The team used the data-flow map to turn the details into operating choices the PM could assign, monitor, and escalate:
Population. Strategic Pull was Broad enough to support future use. Operational Warning was Too broad may increase variability and safety complexity.
Comparator. Strategic Pull was Placebo add-on may show signal clearly. Operational Warning was Rescue rules and ethics must protect participants.
Dose. Strategic Pull was Multiple arms support dose selection. Operational Warning was More arms increase supply, randomization, site training, and sample size.
Endpoint. Strategic Pull was HbA1c is familiar and relevant. Operational Warning was Visit timing, rescue therapy, discontinuation, and missing data affect interpretation.
An estimand [ICH E9(R1)] is the treatment effect the trial is trying to estimate for a defined population, endpoint, treatment condition, intercurrent-event strategy, and population-level summary. An intercurrent event [ICH E9(R1)] is something that happens after treatment starts and affects interpretation, such as discontinuation, rescue medication, treatment switching, or death.
The PM does not need to design the estimand [ICH E9(R1)].
But the PM should recognize when operational events can damage the treatment question.
Lauren asked Claire, "So if rescue medication is common, that is not just a safety or operations issue?"
"Correct," Claire said. "It may change what effect we can interpret."
Samuel added, "And rescue medication cannot be treated as a nuisance. It protects patients."
That is the work: keeping evidence and ethics in the same room.
10.7 Assumptions That Must Be Visible Before Protocol Drafting
An assumption is something the team is treating as true before it has been confirmed.
Every protocol concept contains assumptions. That is normal. The danger is hidden assumptions.
Lauren created a DIAB-220 assumption register. An assumption register is a simple table that records major assumptions, the evidence supporting them, who owns them, how they will be tested, and what happens if they are wrong.
An interactive response technology (IRT) system may support randomization, treatment assignment, and investigational product supply. Electronic data capture (EDC) is the system used to collect and manage clinical study data. Electronic clinical outcome assessment (eCOA) tools collect outcomes electronically, often from participants, clinicians, or observers. A contract research organization (CRO) is an external organization that may perform trial services for the sponsor. A vendor is an external provider of specific trial services, such as labs, imaging, eCOA, drug supply logistics, translation, or data services.
The team used the data-flow map to turn the details into operating choices the PM could assign, monitor, and escalate:
Eligible patients are findable. This matters because drives site count, timeline, and budget: the accountable owner was Site Strategy.; pre-lock test was Targeted site feasibility and database review.
HbA1c endpoint can be collected reliably. This matters because drives endpoint credibility: the accountable owner was Medical/Data Management.; pre-lock test was Lab vendor review, visit-window review, data-flow check.
Rescue rules are ethical and interpretable. This matters because protects patients and analysis: the accountable owner was Medical/Statistics.; pre-lock test was Cross-functional review of rescue triggers and estimand [ICH E9(R1)] impact.
Three dose arms are operationally manageable. This matters because drives randomization, supply, and training: the accountable owner was Supply/Operations.; pre-lock test was IRT and supply scenario planning.
Background therapy can be standardized enough. This matters because affects comparability and recruitment: the accountable owner was Medical/Regulatory.; pre-lock test was Regional standard-of-care assessment.
Twenty-four weeks is acceptable to sites and patients. This matters because affects retention and missing data: the accountable owner was Feasibility/Patient Engagement.; pre-lock test was Site and patient burden review.
Budget can absorb complexity. This matters because determines realism of timeline and scope: the accountable owner was Finance/Operations.; pre-lock test was Concept-level cost model.
Regulatory discussion can support the path. This matters because reduces development uncertainty: the accountable owner was Regulatory.; pre-lock test was Meeting strategy and briefing-package plan.
The assumption register does not make uncertainty disappear.
It keeps uncertainty from disguising itself as a plan.
Maya Desai was blunt about this.
"If we call every unknown a manageable detail, the budget will become fiction."
Maggie added, "And the sites will be the first people asked to make the fiction real."
10.8 The Cross-Functional Concept Review
Concept review is the moment when a product idea becomes a proposed shared operating commitment for governance.
It should not be a ceremonial meeting.
A strong concept review includes the people who can see different failure modes:
The team used the vendor oversight plan to turn the details into operating choices the PM could assign, monitor, and escalate:
Medical. They must test clinical rationale, patient safety, disease relevance, endpoint meaning.
Biostatistics. They must test design interpretability, endpoint hierarchy, estimand [ICH E9(R1)] implications, sample size logic.
Regulatory Affairs. They must test fit with regulatory expectations, agency interaction needs, regional concerns.
Clinical Operations. They must test study conduct model, site workflow, monitoring needs, timeline realism.
Safety/Pharmacovigilance. They must test safety monitoring, adverse-event pathways, risk-benefit implications.
Data Management/Systems. They must test data capture, edit checks, transfers, integrations, endpoint data flow.
Site Strategy/Feasibility. They must test patient availability, competing trials, site burden, country/site mix.
Patient Engagement/Diversity. They must test participant burden, access, equity, retention, meaningful outcomes.
CRO/Vendor Management. They must test outsourcing model, vendor capability, scope clarity, oversight needs.
Supply/IRT. They must test packaging, labeling, randomization, depot model, resupply, expiry.
Budget/Contracts. They must test cost drivers, contracting assumptions, contingency, false economy.
Quality/TMF. They must test critical-to-quality [ICH E8(R1)] factors, inspection-ready rationale, documentation traceability.
Governance/Communications. They must test decision rights, executive framing, unresolved tradeoffs, dissent.
An adverse event is any unfavorable medical occurrence in a participant, whether or not it is considered related to the product. A serious adverse event is an event that meets seriousness criteria such as death, life-threatening event, inpatient hospitalization or prolongation of existing hospitalization, persistent or significant disability or incapacity, congenital anomaly or birth defect, or another important medical event. Concept-stage safety thinking does not replace the later safety-management plan, but it should identify whether the study idea creates special safety burden or monitoring needs.
Grace Kim reminded the team that quality begins before the first site opens.
"Critical-to-quality [ICH E8(R1)] factors are not decoration," she said. "They are the features most important to participant protection, data integrity, reliable results, and the study's ability to answer its objective."
Helen Park added the documentation view.
"If the concept changes three times, we need to know why. The trial master file [ICH E6(R3)] is not only a storage room at the end."
The trial master file [ICH E6(R3)] (TMF) is the collection of essential documents that demonstrate how a trial was conducted and the quality of the data produced. Chapter 12 and Chapter 20 will spend more time with startup documents and inspection readiness. Here, the point is simple: concept decisions should leave a trail.
10.9 When Strategy Wants More Than One Trial Can Carry
One of the hardest things to say in development is this:
This study cannot do all of that.
It sounds negative.
It is often the most useful sentence in the room.
For DIAB-220, the team wanted dose selection, glycemic efficacy, tolerability, weight signal, patient experience, cardiovascular reassurance, broad population relevance, digital adherence insight, payer interest, and future label support.
Each ambition had logic.
Together, they threatened the concept.
The team used a decision log [PMBOK] to make the tradeoff explicit and record what each option would protect or sacrifice:
The team used the data-flow map to turn the details into operating choices the PM could assign, monitor, and escalate:
Dose selection. can chapter 10 concept carry it? means Yes, as primary decision. Better Handling was Protect dose-response and primary endpoint.
Glycemic efficacy. can chapter 10 concept carry it? means Yes, as central evidence. Better Handling was Anchor on HbA1c and endpoint timing.
Tolerability. can chapter 10 concept carry it? means Yes, as key safety evidence. Better Handling was Define monitoring and discontinuation capture.
Weight signal. can chapter 10 concept carry it? means Yes, as secondary context. Better Handling was Avoid overclaiming.
Patient-reported burden. can chapter 10 concept carry it? means Yes, if instrument and burden are feasible. Better Handling was Keep focused and fit for purpose.
Cardiovascular reassurance. can chapter 10 concept carry it? means Partly, not definitively. Better Handling was Capture safety signals; plan later outcomes strategy.
Broad real-world use. can chapter 10 concept carry it? means Not fully. Better Handling was Use separate observational evidence plan.
Payer differentiation. can chapter 10 concept carry it? means Not as primary purpose. Better Handling was Preserve relevant data without distorting trial.
This table did not make leadership less ambitious.
It made ambition governable.
A strong PM learns to separate "not in this trial" from "not important." Some questions belong in the current study. Some belong in a later study. Some belong in observational evidence. Some belong in exploratory analyses. Some should be dropped because they are attractive but not useful.
The protocol concept should say this plainly.
10.10 The CONCEPT Worksheet
Lauren eventually turned the team's discussion into a worksheet.
CONCEPT became the memory structure for this chapter:
The team used the enrollment forecast and site activation tracker to turn the details into operating choices the PM could assign, monitor, and escalate:
C: Clarify the Product Decision. The PM should ask: What business, clinical, regulatory, or development decision must this trial support.
O: Outline the Intended Claim. The PM should ask: What future label, evidence, publication, payer, or clinical-use story is this study meant to enable.
N: Name the Core Population. The PM should ask: Who must be studied for the answer to matter?.
C: Choose the Critical Endpoints. The PM should ask: Which outcomes prove, support, or contextualize the decision?.
E: Expose Assumptions. The PM should ask: What must be true about dose, comparator, timeline, event rate, adherence, safety, recruitment, and operations.
P: Pressure-Test Feasibility. The PM should ask: Sites, patients, vendors, systems, supply, and budget support the concept?.
T: Translate Into Protocol Inputs. The PM should ask: What must be handed to the protocol-writing team without pretending the protocol is already finished.
The practical concept package should include:
The team used the safety governance pathway to turn the details into operating choices the PM could assign, monitor, and escalate:
Protocol concept one-pager. The purpose is summarizes decision, rationale, design, population, intervention, comparator, endpoint, duration, geography, and top risks.
Strategy-to-concept traceability table. The purpose is shows how strategic need becomes evidence question, study objective, design feature, and operational implication.
Assumption register. The purpose is distinguishes confirmed facts from optimistic assumptions.
Concept-level risk register [PMBOK]. The purpose is identifies risks that may damage participant protection, data credibility, timeline, budget, or decision usefulness.
Decision log [PMBOK]. The purpose is records who decided what, when, why, and with what unresolved dissent.
Concept review agenda. The purpose is forces medical, statistics, regulatory, safety, operations, feasibility, vendors, data, supply, budget, quality, and patient input into one review.
Governance summary. The purpose is makes the decision, tradeoffs, assumptions, and next actions clear for leaders.
Here is a simple protocol concept one-pager structure:
The team used the vendor oversight plan to turn the details into operating choices the PM could assign, monitor, and escalate:
Product strategy link. The PM should ask: What part of the TPP or CDP does this study support.
Study decision. The PM should ask: What decision will this study enable.
Study rationale. The PM should ask: Why is this study needed now?.
Target indication and population. The PM should ask: Who is being studied, and why this group?.
Design summary. The PM should ask: What type of study is proposed, and why.
Intervention and comparator. The PM should ask: What will participants receive or be compared against.
Objectives and endpoints. The PM should ask: What will be measured, and what is primary.
Key feasibility assumptions. The PM should ask: What must be true for the concept to work.
Patient and site burden. The PM should ask: What will participation and site conduct require.
Vendor/system needs. The PM should ask: What external services and systems are implied.
Safety and risk-benefit considerations. The PM should ask: What must be monitored or protected.
Governance decision. The PM should ask: What is approved, deferred, rejected, or escalated.
For interviews, a strong answer sounds like this:
"When I help translate product strategy into a protocol concept, I start by clarifying the decision the study must support. Then I make sure the intended claim, population, comparator, endpoints, and feasibility assumptions align. I do not try to make medical or statistical decisions alone, but I do make unresolved assumptions visible and bring the right functions into governance before the full protocol is drafted."
That is not glamorous.
It is leadership.
10.11 What the PM Should Hand Forward to Protocol Development
At the end of the DIAB-220 concept review, Caroline asked Lauren what would be handed to the protocol-writing team.
Lauren no longer said, "the protocol."
She said:
- endorsed protocol concept;
- decision rationale;
- approved primary objective and endpoint direction;
- population and comparator assumptions;
- dose-arm rationale;
- key feasibility questions to test;
- safety and rescue-rule issues requiring protocol detail;
- data and system implications;
- supply and IRT assumptions;
- vendor needs requiring early scoping;
- budget and timeline assumptions;
- open questions, owners, and due dates;
- governance decision record and dissent.
That was the right answer.
Chapter 11 will take those inputs into protocol development and operational feasibility. It will get closer to schedules of assessments, eligibility wording, endpoint operationalization, country and site feasibility, vendor specifications, monitoring strategy, and review cycles.
Chapter 10 stops one step earlier because that step deserves respect.
Before a protocol can be written well, the concept must be true enough to write from.
Lauren closed her notebook and said, "So the concept is where we find the problems while they are still cheap."
Maya laughed.
"Cheap is optimistic," she said. "But cheaper than an amendment."
She was right.
Daniel Liang's Senior Lens
Daniel reminded the concept team that product strategy can ask a question a protocol cannot safely carry. His rule was simple: ambition belongs in strategy, but only executable, reviewable commitments belong in the protocol concept.
Dialogue Closure
The conversation in this chapter closes with a practical management action: Daniel tells Lauren to separate ambition from commitment: strategy can be broad, but protocol concepts need owners, assumptions, evidence, and decision points. The PM should leave the room with a named owner, a documented decision or issue, a reusable tool, and the next review point.
Tool Demonstration In This Chapter
In DIAB-220, Maya Desai used the Project charter and the Protocol synopsis and expanded synopsis review to connect concept approval to operational feasibility before protocol lock. The team did not treat these as extra tables. They used them as working controls: first to name the signal, then to assign the accountable owner, identify the evidence source, document the decision or escalation trigger, and set the next review date.
The reusable lesson is that the tool matters only when it changes behavior. In this chapter, the Project charter made the problem visible, while the Protocol synopsis and expanded synopsis review turned that visibility into an operational decision, closure evidence, or an accepted residual risk.
PM Tools From This Chapter
The tools below connect the chapter story to the master Clinical Trial PM Toolkit. Use the chapter examples to understand the situation, then use the canonical toolkit artifact so the team works from a consistent PMBOK-aligned structure.
The team used the stakeholder map [PMBOK] and communication plan [PMBOK] to turn the details into operating choices the PM could assign, monitor, and escalate:
Product-to-protocol charter. Use this to define purpose, scope, assumptions, success measures, authority, and the clinical reason the project exists.
Assumption log. Use this to capture risks, assumptions, issues, and dependencies with owners, triggers, due dates, and CTQ impact.
Stakeholder map [PMBOK]. Use this to match audiences, concerns, message, timing, owner, and escalation path.
Decision log [PMBOK]. Use this when the team needs a recorded decision with evidence, rationale, owner, dissent, residual risk, and follow-up.
Canonical PMBOK Tool Applications
This chapter uses the following canonical tools from the Clinical Trial PM Toolkit in the context of concept-to-protocol planning and strategic authorization:
- Project charter: Apply this when concept approval, protocol strategy, rescue restart, major phase transition. In this chapter, it helps the team convert the story problem into owned evidence, a decision path, and a follow-up rhythm so the reader can see why the artifact changes the project discussion.
- Phase charter: Apply this when startup launch, enrollment rescue, database-lock push, closeout. In this chapter, it helps the team convert the story problem into owned evidence, a decision path, and a follow-up rhythm so the reader can see why the artifact changes the project discussion.
- Stakeholder register: Apply this when any new trial, vendor transition, inspection, country expansion. In this chapter, it helps the team convert the story problem into owned evidence, a decision path, and a follow-up rhythm so the reader can see why the artifact changes the project discussion.
- Scope baseline: Apply this when protocol finalization, vendor contracting, amendment planning. In this chapter, it helps the team convert the story problem into owned evidence, a decision path, and a follow-up rhythm so the reader can see why the artifact changes the project discussion.
- Work breakdown structure (WBS): Apply this when building the integrated project plan. In this chapter, it helps the team convert the story problem into owned evidence, a decision path, and a follow-up rhythm so the reader can see why the artifact changes the project discussion.
- WBS dictionary: Apply this when when scope is complex or delegated. In this chapter, it helps the team convert the story problem into owned evidence, a decision path, and a follow-up rhythm so the reader can see why the artifact changes the project discussion.
- Communication plan: Apply this when all trials. In this chapter, it helps the team convert the story problem into owned evidence, a decision path, and a follow-up rhythm so the reader can see why the artifact changes the project discussion.
- Site communication plan: Apply this when startup, amendments, safety updates, rescue. In this chapter, it helps the team convert the story problem into owned evidence, a decision path, and a follow-up rhythm so the reader can see why the artifact changes the project discussion.
- Vendor closeout checklist: Apply this when study or vendor closeout. In this chapter, it helps the team convert the story problem into owned evidence, a decision path, and a follow-up rhythm so the reader can see why the artifact changes the project discussion.
For the canonical artifact definitions, see Clinical Trial PM Toolkit.
After Reading This Chapter, You Should Be Able To Answer
If you understand this chapter, you should be able to answer the following questions comfortably and correctly. These questions are part of the reusable clinical project director question bank, so the same operational problem may appear in more than one chapter from a different management angle.
- 1. How is product strategy different from a protocol concept?
- Comfortable answer: Strategy names ambition; the protocol concept turns it into a testable, executable, reviewable study idea.
- 2. What assumptions should be visible before protocol drafting?
- Comfortable answer: Population, comparator, dose, endpoint, geography, vendors, systems, feasibility, budget, and regulatory assumptions.
- 3. How could BIOSIM-701 appear at concept stage?
- Comfortable answer: The concept should define test/reference products, fasting/fed conditions, crossover logic, PK endpoints, and bioanalytical needs.
- 4. What should Daniel Liang do when strategy asks for too much?
- Comfortable answer: Separate ambition from commitments and require owners, evidence, tradeoffs, and decision points.
- 5. What makes a trial concept decision-ready?
- Comfortable answer: Clear objective, population, endpoint, comparator, operational assumptions, risk, owner, and governance path.
- 6. Why should PMs avoid premature operational promises?
- Comfortable answer: Early promises can become unrealistic protocol, budget, vendor, and timeline commitments.
- 7. How should cross-functional concept review work?
- Comfortable answer: Each function names feasibility constraints, evidence needs, risks, and decisions before the concept advances.
- 8. What is the PM's role in product-to-protocol translation?
- Comfortable answer: Make assumptions visible and coordinate accountable expert input without owning the scientific strategy alone.
Evidence Notes for Chapter 10
- ICH E8(R1) supports the chapter's focus on aligning study objectives, design, quality by design, critical-to-quality [ICH E8(R1)] factors, participant protection, reliable results, and planning across the product lifecycle.
- ICH E6(R3) Principles and Annex 1, effective in the European Union from July 23, 2025, support sponsor responsibility, proportionality, quality culture, participant protection, data integrity, and documentation discipline. The chapter does not rely on Annex 2 as current effective instruction.
- FDA's 2007 Federal Register notice for the Target Product Profile draft guidance is used only to support the idea of the TPP as a strategic development and communication tool organized around labeling concepts; the chapter does not present a TPP as binding, final, or approval-guaranteeing.
- FDA enrichment guidance supports the chapter's treatment of population selection as a balance among signal detection, interpretability, applicability, safety, and feasibility.
- ICH E9(R1) supports the chapter's discussion of estimands [ICH E9(R1)], intercurrent events [ICH E9(R1)], endpoints, analysis, and interpretation alignment.
- FDA multiple-endpoints guidance supports the chapter's caution that endpoint hierarchy and multiplicity matter and that secondary or exploratory outcomes should not be overclaimed.
- ICH E17 is relevant to global and multiregional planning considerations when country mix, regional standards of care, and development strategy affect the concept.
- FDA patient-focused drug development and clinical outcome assessment materials support the chapter's emphasis on patient-relevant endpoints, fit-for-purpose measurement, and burden.
- DIAB-220, CARDIA-301, ONCO-214, RARE-007, and VAX-PED-102 are fictional teaching cases. They are designed to illustrate plausible project-management risks, not actual trial results.
References for Chapter 10
- 1. European Medicines Agency. ICH E8 General Considerations for Clinical Studies Scientific Guideline, including E8(R1). https://www.ema.europa.eu/en/ich-e8-general-considerations-clinical-studies-scientific-guideline
- 2. European Medicines Agency. ICH E6(R3) Good Clinical Practice [ICH E6(R3)] Scientific Guideline, Principles and Annex 1 effective in the European Union from July 23, 2025; Annex 2 adopted with later effective date. https://www.ema.europa.eu/en/ich-e6-good-clinical-practice-scientific-guideline
- 3. U.S. Food and Drug Administration. Target Product Profile - A Strategic Development Process Tool. Federal Register notice for draft guidance, March 2007. https://regulations.justia.com/regulations/fedreg/2007/03/30/E7-5949.html
- 4. U.S. Food and Drug Administration. Enrichment Strategies for Clinical Trials to Support Approval of Human Drugs and Biological Products. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/enrichment-strategies-clinical-trials-support-approval-human-drugs-and-biological-products
- 5. U.S. Food and Drug Administration. E9(R1) Statistical Principles for Clinical Trials: Addendum: Estimands [ICH E9(R1)] and Sensitivity Analysis in Clinical Trials. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/e9r1-statistical-principles-clinical-trials-addendum-estimands [ICH E9(R1)]-and-sensitivity-analysis-clinical
- 6. U.S. Food and Drug Administration. Multiple Endpoints in Clinical Trials: Guidance for Industry. Final guidance, October 2022. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/multiple-endpoints-clinical-trials
- 7. European Medicines Agency. ICH Guideline E17 on General Principles for Planning and Design of Multi-Regional Clinical Trials. https://www.ema.europa.eu/en/ich-guideline-e17-general-principles-planning-design-multi-regional-clinical-trials-scientific-guideline
- 8. U.S. Food and Drug Administration. Selecting, Developing, or Modifying Fit-for-Purpose Clinical Outcome Assessments. Guidance for Industry, FDA Staff, and Other Interested Parties. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/selecting-developing-or-modifying-fit-purpose-clinical-outcome-assessments