Chapter 16 / Tools, Statistics, Vendors, Budgets, and Risk Control / Free sample chapter

Chapter 16: Project Planning Tools That Actually Help

How to use standard PM tools without losing clinical trial specificity.

Status Meetings Are Not Project Control

After DIAB-220 reached database lock and moved into analysis and clinical study report (CSR) review, Lauren Brooks opened the original project plan. It looked tidy. There were dates, owners, workstreams, and color-coded milestones.

It also looked less honest than she remembered.

The plan had shown database lock, first tables, listings, and figures (TLFs), CSR draft, final CSR, and governance review as neat steps. It had not shown how many of those dates depended on safety reconciliation, protocol deviation classification, final lab transfers, medical coding, statistical programming, medical review capacity, quality review, and decision timing. It had not shown that one delayed dependency could quietly move the entire finish date.

"We had a plan," Lauren said.

Maggie Chen replied, "You had a calendar. A plan tells you what reality can break."

A project plan is a control tool that connects work, owners, dates, dependencies, assumptions, risks, decisions, and escalation. An integrated timeline shows major workstreams together instead of isolating Clinical Operations, Data Management, Safety, Biostatistics, Regulatory, Quality, vendors, the clinical research organization (CRO), sites, supply, and Medical Writing in separate status slides.

Planning tools are not useful because they look professional. They are useful because they change what the team sees, decides, owns, or does.

The PLANIT Frame

Lauren needed a planning frame she could use without turning every meeting into template maintenance.

PLANIT helped Lauren organize the tools without worshiping them. A timeline answered one question. A risk register [PMBOK] answered another. A decision log [PMBOK] preserved a third. A dashboard showed signal only if it had thresholds, trends, owners, and actions.

The PM's role is to build visibility, cadence, owner clarity, scenario plans, escalation packages, and decision discipline. The PM does not independently approve protocol changes, statistical assumptions, medical judgments, safety determinations, regulatory positions, vendor contract changes, or quality risk acceptance.

What Each Tool Is For

Beginners often collect tools before they know what question each tool answers.

A milestone is an important checkpoint or event. It is not proof that all upstream work is healthy. A deliverable is a concrete output, such as a final protocol, approved informed consent [FDA Informed Consent 2023] form, EDC build, monitoring plan, database lock package, TLF package, or CSR draft. A workstream is a category of related work, such as startup, safety, data, supply, or medical writing.

A constraint is a limit the plan must work within, such as budget, staff capacity, country approvals, vendor timelines, drug supply, or a fixed governance date.

Integrated Timelines And The Critical Path

Lauren rebuilt the DIAB-220 plan as an integrated timeline:

The team used the enrollment forecast and site activation tracker to turn the details into operating choices the PM could assign, monitor, and escalate:

Protocol. Key Milestone was Final protocol. It depends on concept approval, Medical/Biostatistics alignment: the accountable owner was Medical/Clinical.

Startup. Key Milestone was First site activated. It depends on submissions, contracts, EDC, IRT, supply, training: the accountable owner was Clinical Operations/CRO.

Enrollment. Key Milestone was Last patient in. It depends on activated sites, recruitment, retention support: the accountable owner was Clinical Operations/Site Strategy.

Conduct. Key Milestone was Last patient last visit. It depends on visit completion, safety follow-up, retention: the accountable owner was Clinical Operations/CRO/Sites.

Data. Key Milestone was Database lock. It depends on queries, reconciliation, coding, deviation review: the accountable owner was Data Management.

Analysis. Key Milestone was First TLFs. It depends on locked data, SAP, programming QC: the accountable owner was Biostatistics/Programming.

Reporting. Key Milestone was Final CSR. It depends on tLFs, medical interpretation, safety review, quality review: the accountable owner was Medical Writing/Clinical.

Governance. Key Milestone was Submission or program decision. It depends on final report and decision package: the accountable owner was Sponsor leadership.

The critical path is the sequence of dependent activities that determines the earliest realistic finish date. It does not mean "important tasks." Many important tasks are not on the critical path today, but can become critical if their float disappears.

Float, sometimes called slack, is the time an activity can slip before it moves a downstream milestone.

The team used the safety governance pathway to turn the details into operating choices the PM could assign, monitor, and escalate:

Final deviation classification: the accountable owner was Clinical/Data/Biostatistics. Float was 0 days. Risk If Late was Analysis populations delayed; the PM response was to data listings and clinical review

Final TLF generation: the accountable owner was Biostatistics/Programming. Float was 0 days. Risk If Late was CSR review cannot begin fully; the PM response was to locked data and SAP-ready programming

Safety narrative review: the accountable owner was Safety/Medical Writing. Float was 2 days. Risk If Late was CSR safety section delayed; the PM response was to sAE reconciliation and safety outputs

Medical interpretation: the accountable owner was Medical/Biostatistics. Float was 0 days. Risk If Late was Executive decision package slips; the PM response was to final TLFs

Quality review: the accountable owner was Quality/Medical Writing. Float was 3 days. Risk If Late was Final CSR approval slips; the PM response was to complete CSR draft

Tasks with float still need ownership. Float is not permission to ignore work; it is a warning buffer.

Dependencies: The Hidden Engine Of Trial Delay

A dependency means one activity needs another activity, decision, document, vendor output, or approval before it can start or finish. A predecessor is the thing that must happen first. A successor is the thing that depends on it.

Lauren built a dependency table instead of asking for general updates:

The team used the safety governance pathway to turn the details into operating choices the PM could assign, monitor, and escalate:

CSR efficacy section. It depends on final primary and secondary TLFs: the accountable owner was Biostatistics. The due date is May 8. Risk If Late was Medical writing stalls; the PM response was to confirm TLF review path and blockers

Final analysis populations. It depends on deviation classification: the accountable owner was Clinical/Data/Biostatistics. The due date is May 3. Risk If Late was Population rules unresolved; the PM response was to escalate decision owners

Safety summary. It depends on aE/SAE reconciliation and coding: the accountable owner was Safety/PV/Coding. The due date is May 5. Risk If Late was Safety outputs reworked; the PM response was to track reconciliation closure

Appendix package. It depends on tMF essential records [ICH E6(R3)]: the accountable owner was TMF/Quality. The due date is May 10. Risk If Late was CSR appendices incomplete; the PM response was to verify filing and QC dates

Executive readout. It depends on medical interpretation and quality review: the accountable owner was Medical/Quality. The due date is May 16. Risk If Late was Governance delayed; the PM response was to prepare options if review slips

"Pending with function" is not ownership. A useful plan names a person or accountable role, a date, an escalation trigger, and the downstream effect.

RACI Without Theater

A RACI can clarify who is Responsible, Accountable, Consulted, and Informed. Responsible means doing the work. Accountable means owning the outcome or decision. Consulted means giving input. Informed means needing awareness.

RACI does not replace standard operating procedures, contracts, job descriptions, regulations, or governance. It is a clarity tool, not a magic wand.

For the DIAB-220 database lock decision:

Pharmacovigilance, or PV, is the safety function that manages safety information and reporting processes.

The team used the safety governance pathway to turn the details into operating choices the PM could assign, monitor, and escalate:

Query closure. Data Management was A/R. Clinical was C. Safety/pv was C. Biostatistics was C. Quality was I; pm means I.

Safety reconciliation. Data Management was C. Clinical was C. Safety/pv was A/R. Biostatistics was I. Quality was I; pm means I.

Deviation classification. Data Management was C. Clinical was A/R. Safety/pv was C. Biostatistics was C. Quality was I; pm means I.

Lock readiness checklist. Data Management was A/R. Clinical was C. Safety/pv was C. Biostatistics was C. Quality was C; pm means R.

Final lock approval. Data Management was A. Clinical was C. Safety/pv was C. Biostatistics was C. Quality was C; pm means R/I.

Governance escalation. Data Management was C. Clinical was C. Safety/pv was C. Biostatistics was C. Quality was C; pm means R.

Lauren used the RACI when a CSR review comment asked whether three deviations should be excluded from a per-protocol population. The PM did not "just make the call." She routed the question to Clinical and Biostatistics, confirmed the accountable decision owner, captured the rationale, and tracked the impact on TLFs and CSR text.

Risk Register Versus Issue Log

A risk is a possible future event or condition. An issue is already happening.

Teams blur those words when they are nervous. The distinction matters because risks need mitigation and contingencies; issues need recovery actions and closure.

The team used the risk register [PMBOK] to turn the details into operating choices the PM could assign, monitor, and escalate:

Risk. For example, medical review capacity may be insufficient for CSR comments. Tool was Risk register [PMBOK]. The PM should ask: What mitigation and trigger prevent delay.

Issue. For example, safety reconciliation has missed two dates. Tool was Issue log [PMBOK]. The PM should ask: Who owns recovery, by when, and what escalates?.

Assumption. For example, first TLF review will take five business days. Tool was Assumptions log. The PM should ask: This based on actual cycle time.

Decision. For example, move CSR finalization by five business days. Tool was Decision log [PMBOK]. The PM should ask: Who approved, why, and what downstream dates changed?.

Action. For example, priya to confirm lab transfer exception closure by Friday. Tool was Action tracker. The PM should ask: What evidence proves closure.

A risk register [PMBOK] should include cause, impact, probability, mitigation, contingency, trigger, and owner. An issue log [PMBOK] should include current impact, owner, due date, escalation path, and closure evidence. An assumptions log captures beliefs the plan depends on. Assumptions become dangerous when teams start treating them as facts.

Decision Logs And Governance Memory

Governance agreed to move DIAB-220 CSR finalization by five business days so Safety could complete reconciliation and Medical Writing could update the safety section with stable outputs. Three weeks later, someone asked why the submission package had slipped.

The answer should not live in meeting chat.

The team used the risk register [PMBOK] to turn the details into operating choices the PM could assign, monitor, and escalate:

Move CSR finalization by five business days. Date was May 4: the accountable owner was Asset governance chair. Options Considered was Hold date with risk acceptance; move date; reduce review scope; rationale was Safety reconciliation not complete enough for credible CSR finalization; impact was readout prep and submission package shifted five business days.

A decision log [PMBOK] protects organizational memory. It records the decision, date, accountable decision-maker, rationale, options considered, assumptions, and affected documents or workstreams. It prevents teams from relitigating decisions after context fades.

It also protects the PM. Lauren could explain what changed because the record existed.

Meeting Cadence That Moves Work

Meeting cadence is the rhythm of recurring meetings and reviews. More meetings do not create control. Better meetings do.

Lauren redesigned the DIAB-220 cadence:

The team used the vendor oversight plan to turn the details into operating choices the PM could assign, monitor, and escalate:

Daily lock-to-CSR huddle. The purpose is remove immediate blockers. Should Decide was Owner/date changes, same-week escalations. Should Not Become was A full status recital.

Weekly study team. The purpose is integrate cross-functional progress. Should Decide was Dependency and risk updates. Should Not Become was A slide-reading ceremony.

Data review meeting. The purpose is to resolve data, query, coding, reconciliation issues. Should Decide was Data-readiness actions. Should Not Become was A place for commercial speculation.

Vendor/CRO review. The purpose is to review delivery quality and issue closure. Should Decide was Escalation for transfer, query, or staffing problems. Should Not Become was Activity reporting without evidence.

Governance forum. The purpose is make cross-functional decisions. Should Decide was Risk acceptance, timeline changes, resource decisions. Should Not Become was A surprise briefing.

Minutes should capture decisions, actions, owners, due dates, and escalation triggers. An action tracker is useful only when items are current, owned, dated, and closed with evidence.

The team used the safety governance pathway to turn the details into operating choices the PM could assign, monitor, and escalate:

Confirm SAE reconciliation complete: the accountable owner was Safety/PV lead. The due date is May 5. Status was At risk; evidence was Signed reconciliation report. The trigger was Missed date affects lock.

Resolve lab transfer exception: the accountable owner was Central lab vendor/Data. The due date is May 3. Status was Open; evidence was Rejected-record log cleared. The trigger was No file by noon Friday.

Finalize deviation classification: the accountable owner was Clinical/Data/Biostatistics. The due date is May 4. Status was Open; evidence was Approved deviation listing. The trigger was Disagreement remains after review.

Dashboards That Tell The Truth

A dashboard is only as useful as the conversation it forces.

The old DIAB-220 dashboard had many green boxes. The new one had fewer colors and more signal.

Critical-to-quality [ICH E8(R1)] factors, or CTQs, are the aspects of a trial most important to participant protection and reliable results. Planning tools should not treat every task as equally important; timelines, risk registers [PMBOK], dashboards, and escalation triggers should pay special attention to CTQs, participant safety, data reliability, feasibility assumptions, and quality risks. That is how quality-by-design and risk-based quality thinking become practical PM behavior instead of slogan language.

The team used the data-flow map to turn the details into operating choices the PM could assign, monitor, and escalate:

Database lock. Weak Dashboard was Green: "on track". Decision-useful Dashboard was Critical path: two CTQ queries and one safety reconciliation item due by May 5.

Query status. Weak Dashboard was 92 percent closed. Decision-useful Dashboard was 8 endpoint/safety queries open; 3 over 30 days; owners and dates visible.

CSR progress. Weak Dashboard was Draft in progress. Decision-useful Dashboard was Efficacy section blocked until final TLF review; safety section pending reconciliation.

Vendor delivery. Weak Dashboard was Lab transfer sent. Decision-useful Dashboard was Transfer accepted, rejected records cleared, reconciliation signed off.

Risk. Weak Dashboard was No red items. Decision-useful Dashboard was Top 3 risks with trigger, mitigation, contingency, and owner.

Decisions. Weak Dashboard was None. Decision-useful Dashboard was Two governance decisions needed this week.

Leading indicators warn before a milestone fails: query aging, transfer rejection rate, review-cycle time, action aging, staffing gaps, and unresolved decisions. Lagging indicators tell what already happened: missed lock date, late CSR, budget overrun, delayed readout.

Key performance indicators, or KPIs, measure performance. Key risk indicators, or KRIs, warn about emerging risk. Both are useful only when they are tied to thresholds and action.

Reforecasting Without Shame

Reforecasting means updating the forecast using current evidence. It is not failure. It is mature control.

The baseline plan is the approved version of the plan used for comparison. Variance is the difference between the baseline and what is actually happening.

The baseline plan said final CSR would be ready June 14. Actuals said otherwise: lock was five days late, first TLF review took seven business days instead of five, Medical had limited review capacity, and Quality requested an additional review cycle.

Lauren prepared a reforecast:

The team used the quality management plan [PMBOK] to turn the details into operating choices the PM could assign, monitor, and escalate:

Database lock. The baseline is may 1: the actual evidence showed Locked May 6; the revised forecast created 5-day downstream pressure; options included Compress noncritical review only if quality agrees.

First TLF review. The baseline is 5 business days: the actual evidence showed 7 business days; the revised forecast created +2 days; options included Add reviewer capacity or shift final date.

Safety section. The baseline is parallel drafting: the actual evidence showed Awaited reconciliation; the revised forecast created +3 days risk; options included Prioritize safety review and update CSR sequence.

Quality review. The baseline is 3 days: the actual evidence showed Requires 5 days; the revised forecast created +2 days; options included Move governance review or add earlier pre-review.

Final CSR. The baseline is june 14: the actual evidence showed Current evidence says June 23; the revised forecast created +7 business days; options included Hold with risk acceptance, add resources, or reset date.

Scenario planning gives leadership choices:

The team used the safety governance pathway to turn the details into operating choices the PM could assign, monitor, and escalate:

Best case. Assumption was Added reviewers and no new comments. Consequence was Final CSR slips three business days.

Base case. Assumption was Current review pace continues. Consequence was Final CSR slips seven business days.

Worst case. Assumption was Safety or TLF issue requires rework. Consequence was Final CSR slips two to three weeks.

Caroline Whitaker helped Lauren turn the reforecast into executive language:

"The original CSR date no longer reflects actual cycle time. We can hold the date only by accepting reduced review margin, adding temporary reviewers, or moving noncritical appendices after core text review. The recommended base-case reset is June 23, with a three-day best-case recovery if reviewer capacity is added by Friday."

That is not alarming leadership. That is giving leadership a usable choice.

Executive-Ready Planning

Senior leaders do not need every task. They need the shape of the decision.

Lauren's one-page governance update had five parts:

The team used the decision log [PMBOK] to turn the details into operating choices the PM could assign, monitor, and escalate:

Milestone status. Content was What changed since last report and why.

Critical path. Content was Which dependent work controls the finish date.

Top risks/issues. Content was Only decision-relevant items with owners and dates.

Options. Content was Real choices with tradeoffs, not one disguised recommendation.

Decision needed. Content was Who must decide what by when.

Governance escalation is not complaining upward. It is moving unresolved cross-functional decisions to the forum that has authority to choose.

Escalation triggers for DIAB-220 included critical path movement, CTQ risk, missed milestone, budget/timeline divergence, unresolved cross-functional decision, safety or data-quality concern, vendor underperformance, or sponsor risk acceptance. The PM should escalate before the surprise becomes unavoidable.

Planning Tools And PM Boundaries

Good planning tools can tempt a PM into overreach because the PM sees everything.

Seeing everything does not mean owning every decision.

The team used the quality management plan [PMBOK] to turn the details into operating choices the PM could assign, monitor, and escalate:

Build integrated plan and dependency map. Accountable Functions Decide was Protocol changes, eligibility criteria, and medical judgments.

Track risks, issues, decisions, and actions. Accountable Functions Decide was Statistical assumptions and analysis methods.

Reforecast based on actual evidence. Accountable Functions Decide was Safety causality, seriousness, and reportability.

Prepare governance options. Accountable Functions Decide was Regulatory positions and submission commitments.

Escalate unclear accountability. Accountable Functions Decide was Quality risk acceptance and CAPA adequacy.

Expose vendor/CRO delivery gaps. Accountable Functions Decide was Contract changes, payment terms, and procurement decisions.

The PM's authority comes from visibility, discipline, and timing. A strong PM does not command the whole trial. A strong PM keeps the whole trial from lying to itself.

What Lauren Learns

Lauren entered Chapter 16 thinking planning meant maintaining the plan. She left understanding that planning means maintaining truth.

A good plan does not prevent surprises. It makes assumptions, dependencies, weak signals, and hard choices visible earlier. A risk register [PMBOK] does not manage risk by existing. A dashboard does not prove health by being green. A RACI does not create courage. A meeting cadence does not create control unless decisions and actions move.

Lauren's better interview answer became:

"I manage plans as living decision systems. I track critical path, float, dependencies, risks, issues, decisions, actions, owners, forecast variance, and governance options together. When the plan changes, I quantify impact and bring realistic choices."

Chapter 17 begins from the planning insight Chapter 16 creates: the PM does not need to become the statistician, but she must understand enough statistical dependency to plan honestly around SAP approval, data readiness, TLF review, interpretation, and decision timing.

Daniel Liang's Senior Lens

Daniel treated tools as a leadership language. "A charter, RACI, RAID log, timeline, decision log, and communication plan are not paperwork," he told the department. "They are how a team agrees what reality requires next."

PMBOK and Clinical Term Integration

A schedule variance is the difference between the approved timing baseline and actual or forecast timing. In clinical trials, the PM should not report variance as a single red date. The useful diagnosis separates startup delay, enrollment underperformance, vendor readiness, data-cleaning bottleneck, regulatory review, supply constraint, budget decision, and governance delay.

The problem-to-tool index is the reader's lookup map from operational pain to a standard PM artifact. If the problem is slow enrollment, start with feasibility, risk, and issue tools; if the problem is vendor failure, start with SOW, KPI/KRI, issue, and governance tools; if the problem is inspection pressure, start with evidence mapping and request tracking.

A tool shell is a reusable artifact structure, not a substitute for thinking. The point of a shell is to make evidence comparable across chapters, projects, vendors, and meetings. The PM still has to write the situation clearly enough that the team understands the decision, risk, owner, and next action.

Dialogue Closure

The conversation in this chapter closes with a practical management action: Daniel teaches that tools are shared language. The PM should standardize charters, RACI, RAID, timelines, decision logs, and communication plans so the team solves new problems without inventing new control systems. 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 CARDIA-301, Caroline Whitaker used the Work breakdown structure (WBS) and the Schedule network to translated a slipping dashboard into work packages, dependencies, and forecast choices. 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 Work breakdown structure (WBS) made the problem visible, while the Schedule network 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 risk register [PMBOK] to turn the details into operating choices the PM could assign, monitor, and escalate:

Project charter [PMBOK]. Use this to define purpose, scope, assumptions, success measures, authority, and the clinical reason the project exists.

Work breakdown structure. Use this as the chapter-specific adaptation of the standard project-management toolkit.

Integrated timeline. Use this to connect milestones, dependencies, owners, dates, float, blockers, and recovery options.

RAID and decision logs [PMBOK]. Use this to capture risks, assumptions, issues, and dependencies with owners, triggers, due dates, and CTQ impact.

Canonical PMBOK Tool Applications

This chapter uses the following canonical tools from the Clinical Trial PM Toolkit in the context of integrated planning, WBS, schedule, risk, RACI, dashboards, and reforecasting:

• 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.
• Governance and decision-rights map: Apply this when complex cross-functional work or divided leadership. 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.
• Deliverables register: Apply this when vendor-heavy or submission-facing studies. 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.
• Protocol-to-operations traceability map: Apply this when protocol review, startup, amendment impact. 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.
• Requirements and interface matrix: Apply this when ecoa, irt, central lab, imaging, edc, safety database. 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.
• RACI / responsibility assignment matrix: Apply this when role confusion, sponsor/cro/vendor boundaries. 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.
• Risk register: Apply this when planning and monitoring. 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.
• Issue log: Apply this when any realized blocker. 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.
• Change request form: Apply this when protocol, scope, vendor, schedule, budget, system, monitoring changes. 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.
• Cost baseline: Apply this when budget authorization. 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.
• Forecast tracker: Apply this when monthly finance review. 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.
• Accrual tracker: Apply this when finance close and vendor management. 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. 1. How should a PM use the critical path?

• Comfortable answer: Identify dependencies that determine the earliest credible finish date and manage blockers visibly.

1. 2. What makes a RACI useful rather than decorative?

• Comfortable answer: It clarifies responsible work, accountable decisions, consulted experts, informed stakeholders, and boundary notes.

1. 3. How should a RAID log be maintained?

• Comfortable answer: Separate risks, assumptions, issues, and dependencies; assign owners, dates, triggers, and CTQ impact.

1. 4. What belongs in a decision log?

• Comfortable answer: Decision, owner, evidence, options, rationale, dissent, residual risk, action, and record location.

1. 5. How should Daniel Liang standardize project tools?

• Comfortable answer: Use shared shells so teams solve new problems without inventing new control systems.

1. 6. When should a dashboard be challenged?

• Comfortable answer: When it reports color without evidence, risk, decisions, aging issues, or participant/data impact.

1. 7. What should trigger reforecasting?

• Comfortable answer: Evidence that assumptions about sites, vendors, data, supply, budget, or approvals are no longer true.

1. 8. How should planning tools apply beyond DIAB-220?

• Comfortable answer: Use the same shells for BA-BE, pediatric, device, hybrid, registry, and rescue studies with clinical adaptations.

Evidence Notes

• ICH E6(R3) supports the chapter's emphasis on sponsor oversight, quality management, proportionate approaches, essential records [ICH E6(R3)], reliable results, and role clarity.
• ICH E8(R1) supports the chapter's link between planning tools, critical-to-quality [ICH E8(R1)] factors, feasibility, stakeholder input, and designing quality into clinical studies.
• General project-management concepts such as integrated schedules, critical path, responsibility assignment, risk management, issue management, and stakeholder communication are used as practical management concepts rather than clinical trial regulations.
• Industry risk-based quality management methods support the chapter's emphasis on leading indicators, thresholds, risk ownership, and escalation, but the chapter avoids treating any one industry framework as binding regulation.

References

1. 1. International Council for Harmonisation. ICH E6(R3) Good Clinical Practice [ICH E6(R3)].
2. 2. International Council for Harmonisation. ICH E8(R1) General Considerations for Clinical Studies.
3. 3. Project Management Institute. A Guide to the Project Management Body of Knowledge and related PMI standards.
4. 4. ISO 31000, Risk Management Guidelines.
5. 5. TransCelerate BioPharma. Risk Based Quality Management resources.