From One Trial to a Portfolio

Executive summary

There is a point at which a company stops being an organization running a trial and becomes one running a portfolio, and the transition is rarely marked. What this paper offers is how to recognize the inflection early and what to build in what order once it arrives, because the layers depend on each other and the intuitive order is the wrong one.

The thing that breaks first is visibility, not capacity. From inside they look identical, because both present as capable people working harder, and that resemblance is why the strain is usually misdiagnosed as a resourcing problem.

What breaks is visibility. I have run programs where every subteam was well led and every functional group delivered. Participants afterward still reported that they had never seen an integrated view of all the activity, and that program governance and the tactical work had come apart. Both statements were true at once. That is the specific failure of the transition from one program to several, and it explains why it goes undetected: nothing looks broken from inside any individual part.

This paper sets out the tell that identifies the transition point, the four things that break, the oversight problem that scales worst, and the order in which to build the replacement layer.

Examples are drawn from prior engagements and are described by organizational scale only. No organization, program, partner or individual is identified, and no revenue figures, confidential parameters or specifications appear. Where a modality is named it reflects a property of that modality rather than a disclosure about any organization.

1The system that carried the first program

Single-program organizations run on shared context. The head of clinical operations knows the manufacturing schedule. The technical lead knows which sites are enrolling. One person can answer a question about any part of the program without asking anyone.

Shared context substitutes for a great deal of formal infrastructure and substitutes well. Forecasting is unnecessary when one person holds the whole picture. Prioritization is unnecessary when there is one priority. Governance is unnecessary when the decision-makers eat lunch together.

None of that is immaturity. It is the correct operating model for one program, and imposing portfolio machinery on a single-program company wastes money and slows it down.

The problem is that the transition point is invisible from inside. Shared context degrades gradually as programs are added, and the organization compensates without noticing, because compensation looks like people working harder and that is the normal state of an early company.

2The Two-Week Test

Maturity models describe a destination and invite an organization to locate itself on a curve. They are useful for planning and useless for timing, because they cannot say when. The Two-Week Test is a trigger rather than a stage, and it takes one question.

There is a reliable indicator that the transition point has passed, and it is not a metric.

Ask what happens when one specific person takes two weeks of leave. Listen for rescheduled decisions, a deferred vendor conversation, or a general sense that it would be difficult right now. Any of those means the organization is running on individual capacity rather than on a system.

A second tell is where accurate status comes from. If the reliable answer to a program question comes from a conversation rather than a document, there is no shared record, and the cost of that appears when the person holding the answer is unavailable, or leaves.

Both tells are visible long before anything breaks. Neither generates urgency, because both describe a state that feels like ordinary pressure in a growing company.

3What the coordination surface actually looks like

Here is the shape of the problem, from an accelerated program at a global biopharma company running development across multiple business units.

Bringing the full organization onto a single program required a series of structured functional workshops, run in parallel across the areas that had to be aligned.

Exhibit 1. Source: The Modeste Duncan Group analysis.

Exhibit 2. The coordination surface for a single program, fully staffed. Source: The Modeste Duncan Group analysis.

That is roughly ten distinct functional interfaces for one program, each needing its own working session because the questions were different in each. Run that number again for a second program and a third, with overlapping people, and the reason the corridor stops working becomes arithmetic rather than cultural.

The survey I described earlier bears this out from the participants' side. Regular working group meetings were reported as burdensome and essential in the same breath. Coordination between the technical teams was rated as effective. And yet the integrated view was reported as missing. A high volume of well-run coordination in the parts does not aggregate into visibility across the whole. Something has to hold the whole, and at one program that something is a person.

4The four things that break

Resource forecasting

With one program, resource questions are answered by looking. With three, one person sits on the critical path of two and nobody has drawn that picture. The first symptom is a schedule that slips for reasons no one can attribute, because the cause is a person rather than a task.

The forecast that matters at this stage is coarse. Named individuals against named programs, at a monthly grain, with a visible flag where one person appears on two critical paths. Sophisticated capacity modeling adds little at this size. The value comes from making contention visible at all.

Oversight of whoever does the work

The relationship that one senior person managed personally does not scale to several, and sponsor accountability does not scale down with company size. A small sponsor carries the same oversight obligation as a large one.¹²

Data, systems and language

The first program runs on spreadsheets and a single instance of everything, and the file is assembled at the end by effort. At the third program the consequence arrives: nothing is comparable across studies, safety data cannot be pooled without reconciliation⁴, and reconciliation happens under time pressure at the moment it matters most.

The participant finding I keep returning to is that differing standards, methods and processes cause confusion, and that the fix is a shared language agreed in advance.⁵ Also that the system to be followed should be agreed upfront, particularly for quality, with hand-off points and likely areas of misalignment identified early. That is a cheap conversation held early and an expensive reconstruction held late.

Governance cadence

With one program, the leadership meeting is the program meeting. With three, program review and portfolio review are different conversations, and holding them as one produces a predictable failure: the loudest program consumes the agenda and the quiet one is discovered to be in trouble a quarter later.

5The oversight case that scales worst

Most writing on this topic assumes the counterparty is a contract research organization. The harder and more instructive case is a partner whose processes are less developed than yours, which is the common situation for a company built on academic or institutional origination.

From the same program, these are the practices participants recommended for that relationship. I would apply all of them.

Exhibit 3. Two diligences, and the one that usually gets skipped. Source: The Modeste Duncan Group analysis.

Run real diligence on capability, not only on science

Assess the partner's awareness of product development standards using an explicit checklist: ability to ensure regulatory compliance, experience engaging with health authorities, and understanding of operational requirements. Scientific excellence and development readiness are separate assessments and the first is regularly mistaken for the second.

Settle responsibilities, expectations and the contractual position before work starts

including a responsibility matrix and named points of contact on both sides. Also the unglamorous items: expected frequency of communication, documentation requirements with templates supplied, and a mutually agreed work schedule.

Take sponsorship of studies as early as you reasonably can

Where the partner is running work that will support your filing, the accountability is already yours and the control should follow it.²³

Engage early enough to influence design

Reviewing key decisions while they are still decisions is the difference between oversight and archaeology.

Expect a different culture and plan for it

Treating the difference as a performance problem wastes the relationship. Different drivers, different timelines and less developed process are characteristics of the counterparty, and a plan that assumes otherwise will fail on schedule.

At this size, sponsor oversight is a named role rather than a department. One person accountable for partner and vendor performance against defined expectations, with a schedule of oversight activity and a written record of what was reviewed and what was found.

6What to build, and what to leave alone

The instinct is to hire a head of portfolio and buy systems. Both are usually premature and both can make things worse by adding process before the shape of the problem is clear.

The layer that pays for itself first is small.

A single view of programs, milestones and named resources, maintained by one person on a fixed cadence, in one place. A shared tracking template applied identically across internal work and partner work matters more than the sophistication of the tool, because the value is comparability.

A defined sponsor oversight role, as above.

A standard for data, documents and terminology applied from the next study onward. Retrofitting completed studies is rarely worth it. Preventing divergence from here is.

A separated portfolio review at a fixed cadence, with a standing agenda covering every program including the quiet one.

The order to build the portfolio layer

I ran this build at a clinical-stage company moving from one program to several, and the order was the whole of the value.

First, the portfolio and program hierarchy: how work is grouped by franchise, therapeutic area, program and function, agreed before any tool is configured. Then existing plans synchronized into that hierarchy with real data rather than placeholders, using agreed standards for task names, field names and values. Then a resource pool defined by role, mapped against those plans. Then dashboards by function, by role and by program. Then, last, scenario modeling.

Exhibit 4. The build order. Starting at the top is why portfolio tools get abandoned. Source: The Modeste Duncan Group analysis.

Each layer is worthless without the one beneath it. A dashboard built over plans that do not share a task taxonomy reports noise with great confidence. A resource view built over a partial plan tells you nothing about contention, which is the only reason to build it. Scenario modeling over any of that is arithmetic on sand.

Most companies buy the tool and start at the dashboard, because the dashboard is what was demonstrated in the sales meeting. That is why dashboards get abandoned within two quarters and why the organization concludes the tool failed.

The second discipline is to pilot on one part of the portfolio and extend only if the pilot holds. We ran the therapeutics programs first and treated integration of the second franchise as a decision to be made on evidence rather than a phase already scheduled. That framing is cheap to adopt and it is what keeps a failed pilot from becoming a company-wide rollout nobody can stop.

A risk process teams will actually use

Risk registers decay into compliance artifacts for a predictable reason: teams score risks inconsistently, so the register cannot be read across programs, so nobody reads it, so nobody maintains it.

The design I would use again does four things. It defines risk categories in advance, so a risk is classified rather than described. It scores likelihood and impact on a common scale, with impact assessed against cost, performance, time and resource rather than as a single feeling. It requires a trigger, meaning the observable event that tells you the risk is materializing. And it separates mitigation from contingency.

That last distinction carries most of the weight. Mitigation reduces the likelihood that a risk occurs. Contingency is what you do when it occurs anyway. Teams write the first and skip the second, because writing a contingency feels like conceding the mitigation will fail. A register with mitigations and no contingencies is a statement of intent, and the moment a risk lands the team is improvising.

At the portfolio level, consistent scoring is what allows risks to be compared across programs, which is the only way a leadership team can tell whether it is looking at one troubled program or a systemic exposure.

Leave alone: detailed resource algorithms, stage-gate frameworks borrowed from large pharma, and anything requiring a dedicated administrator. Each solves a problem the organization will have in several years and creates one it has now.

7Sequencing

Order by the cost of the failure when it lands.

Exhibit 5. What breaks, sequenced by what the failure costs. Source: The Modeste Duncan Group analysis.

Oversight first

because accountability sits with the sponsor regardless of staffing and the consequences of a gap are regulatory rather than operational.

Data, document and terminology standards second

because divergence compounds with every study started without them.

Resource visibility third

because it is the cheapest to build and gives the fastest relief to the people currently absorbing the strain.

Portfolio governance last

because it depends on the other three to have anything reliable to review. A portfolio meeting held over unreliable inputs produces confident decisions on poor information, which is worse than the corridor conversation it replaced.

Conclusion

The transition from one program to several is the least dramatic and most consequential operational shift an early clinical company makes. It arrives with no event to mark it, and the organization's own competence disguises it.

The window to build cheaply is the quarter before the third program starts. After that, everything on this list still gets built, at higher cost, under pressure, and usually in response to something that has already gone wrong.

From practice. I have sat on both sides of sponsor oversight: inside a contract research organization receiving it, and later accountable for designing it. That is an unusual pair of vantage points and it is where section 5 comes from.

Appendix A · Abbreviations and Key Terms

Appendix B · References

Statutory and regulatory citations reflect settled United States law unless identified as draft. FDA and ICH documents were confirmed against primary sources as of May 2026. Draft guidances are identified as such and remain subject to change. ICH E6(R3) Annex 2 takes effect 15 January 2027 and is cited below as adopted. Citations were verified to September 2026; where a source postdates the paper, the later status is given.

1. International Council for Harmonisation. “ICH Harmonised Guideline: Guideline for Good Clinical Practice E6(R3).” Step 4 adopted 6 January 2025; effective in the European Union 23 July 2025; published by FDA 9 September 2025. Section 10.1: the sponsor may transfer activities but retains overall responsibility. Section 10.2: where activities are transferred to service providers, responsibility for trial conduct, including quality and integrity of the data, resides with the sponsor. Section 10.3: the sponsor should maintain appropriate oversight.

2. 21 C.F.R. §312.50 (general responsibilities of sponsors); 21 C.F.R. §312.52 (transfer of obligations to a contract research organization).

3. U.S. Food and Drug Administration. “Investigator Responsibilities: Protecting the Rights, Safety, and Welfare of Study Subjects; Guidance for Industry.”

4. European Medicines Agency. “Guideline on the content, management and archiving of the clinical trial master file (paper and/or electronic).”

5. International Council for Harmonisation. “ICH E8(R1): General Considerations for Clinical Studies.” Quality by design and critical-to-quality factors.

6. International Council for Harmonisation. “ICH E6(R3) Annex 2.” Step 4 reached 3 June 2026; effective 15 January 2027.

Published May 2026 by The Modeste Duncan Group, which owns this paper and the methods it describes. Clients receive a license to use them;