“Delivered” Is Not the Same as “Ready”

When I was managing CDMO work on the sponsor side, I saw a clinical batch arrive on schedule and still not be usable. The CDMO had delivered the batch record on time. A deviation was still under investigation, and the data that would show whether it affected the product had not yet been generated. Until that data existed, QA could not release the batch.

On paper, the milestone was met. The CDMO had done exactly what it committed to. But anyone who had planned around “batch complete” as if it meant “drug available for the trial” was now waiting on work that had never had a date of its own.

That gap is common, and it is rarely anyone’s fault. The same milestone means different things to different people. Manufacturing hears “the run is finished.” QA hears “the record has been reviewed, release-relevant issues have been assessed, and there is a basis for releasing the product.” Management, preparing for investors, hears “we can start the trial.” All three readings are reasonable. They just don’t share a date.

This article is about that gap: why it forms, why it is so easy to miss when a company is preparing to raise money, and what a team can do before a date goes into the deck rather than after it slips.

Why the plan starts out optimistic

When I worked as special assistant to a company chairman, the delays I saw most often in our own plant were not dramatic failures. They were material shortages. A project schedule would go straight from the decision to manufacture to the production run, with little time for sourcing in between. Procurement takes time, and it does not always go smoothly. The distance between “we have decided to make clinical supply” and “we have released product we can use” is longer than most schedules allow, and less predictable.

It helps to write out what actually sits in that distance. Materials have to be specified, ordered, and delivered. Under GMP, they usually cannot go straight onto the production floor when they arrive; they need to be received, sampled, tested where required, and released for use. Only then can the batch be made. After the run, the executed batch record has to be reviewed, QC testing has to be completed, and any deviation that could affect the batch has to be investigated far enough for the responsible quality role to assess its impact and make a release decision. For clinical supply, packaging, labeling, and shipment to sites also need their own place in the schedule.

Most project schedules show two or three of those steps. The rest are folded into a single bar labeled “manufacturing,” or left out entirely. Each hidden step is small enough that nobody objects to its absence. Together, they are often the difference between the date in the plan and the date the product can actually be used.

Material is the step I would look at first, because it comes before everything else. A delay at the start of the chain can push dependent work back with it, and it is the step people outside operations are least likely to think about. A PM who has never had to chase a late component will reasonably assume that ordering it is the same as having it.

Management wants certainty, and that is not unreasonable

I understand why schedules look the way they do. Management needs a definite result and a definite date to give investors. A board does not want to hear “it depends.” A financing narrative built on “we expect clinical supply sometime between Q2 and Q4” is harder to tell than one built on “first patient dosed in Q3.”

Over time, though, I learned that leadership’s estimates were usually too optimistic. I don’t think that was a failure of judgment, and I don’t think it was management’s fault. Most people know that QA release or material procurement matters. Unless they have worked through it themselves, they don’t know how long it can take or how badly it can go. That knowledge comes from experience, and the people setting the dates often haven’t had that particular experience.

This is the real reason I came to treat cross-functional communication as part of the plan itself, not something that happens around it. Telling someone that a step is important is easy, and they will usually agree. Showing them how serious it can get is the actual work.

In practice, that means translating an operational risk into the terms the other person is already using. “The deviation investigation is still open” means little to someone preparing an investor meeting. “If the investigation needs additional testing, release could move past the date in the deck, and we would be presenting a trial start we can’t yet support” means a great deal. The facts are the same. The second version tells the listener what it means for their own work.

It also means bringing the person with the experience into the room before the date is fixed, not after it has been announced. The QA lead or the person who manages supplier relationships should see the date before it goes onto a slide. Their job in that conversation is not to approve or veto the plan. It is to say what has to be true for the date to hold.

Define what will be usable on the date

Start with what the milestone is meant to support. “GMP batch complete” may be enough for a progress update. It is not enough to tell an investor when dosing can begin. For the supply part of that commitment, the date has to refer to released product available at a site, not to the end of the manufacturing run. The other requirements for dosing still need to be met.

Data milestones work the same way. “Q2 readout” can mean the last experiment finishes, the external lab sends its file, or the team has an interpretation it can defend in front of an investor. Those are three different dates. Write down which one you mean.

Then put the description beside the date. “Released clinical supply available for the first site” sets a clearer expectation than “batch complete.” “Reviewed results ready for discussion of the next development step” sets a clearer expectation than “readout.” A longer label is a small price for removing an assumption that nobody has checked.

If the date is only good for a narrower purpose, say so in the plan. There is nothing wrong with a milestone that means “manufacturing finished, release pending.” The problem only starts when that milestone is read as something more.

Find the handoff the schedule has left out

Work backward from what will be used, and ask each person in the chain what they need before they can start. QA cannot release a batch on the record alone while the impact of a deviation remains unresolved. A clinical team cannot treat “batch complete” as confirmation that supply will be ready for dosing. Schedules usually capture each team’s own work. They often miss the point where one team considers its job done and the next team still cannot begin.

A few questions tend to surface these gaps quickly:

• To procurement: when will materials be in hand and released for use, not just ordered? Which items have long or uncertain lead times, and is there an alternative if one is late?
• To manufacturing or the CDMO: what does “complete” mean in your schedule? When will the executed batch record be ready for review?
• To QA: what must be resolved or assessed before you can make a release decision? If a deviation is raised, what usually determines how long the investigation takes?
• To the team using the output: what do you need in hand before you can start, and in what form?

None of these questions is difficult. The difficulty is that each one is usually asked by a different person at a different time, and the answers are never put side by side.

Someone should own the combined outcome. Each contributor can meet their own date while no one checks whether the pieces add up to something usable. The owner does not make technical calls or take over the release decision. The owner tracks the open handoffs, asks the people doing the work for honest forecasts, and makes sure the answers reach the people making commitments to investors.

Separate the work you can estimate from the questions you can’t

Some steps have a reasonably predictable length once they start. Others depend on an answer that does not exist yet. A deviation investigation is the clearest example. It may close quickly, or it may show that more testing is needed, and nobody can honestly say which until the investigation has progressed.

When a forecast depends on an open question like that, say so. Record the dependency and the date on which you will reassess it. Adding a buffer to the end of the schedule and hoping it covers whatever happens is tempting, but it hides the reason for the uncertainty. When the buffer runs out, nobody can explain why, and the next estimate is trusted even less.

An explicit open question is easier to manage. It tells management what to watch, tells investors what the company is waiting for, and gives the team a clear point at which to update the plan.

A narrower conversation can still happen on time

If investor meetings are already booked, the team does not have to cancel them. It can change what the meeting is for. A progress update can report that manufacturing is complete, that a deviation is under investigation, and that release depends on its outcome. What it should not do is present the trial start date as settled.

Keep the limitation next to the claim it limits. A “preliminary” note at the bottom of a slide does not qualify a headline that says the program is on track. If the headline depends on an open question, the open question belongs in the headline or directly under it.

Keep versions identifiable, too. Early summaries get forwarded and reopened weeks later. Put a date and a version on anything that leaves the company. If a later update changes an earlier statement, point out the change. Don’t leave the reader to find it by comparing decks.

Investors generally expect development programs to run into problems. What damages trust is finding out that a problem was known and not mentioned, or that a date was presented with more confidence than the team actually had.

Explain the consequence when the date changes

“Manufacturing is delayed” tells an investor or a board member very little. They cannot tell whether the delay is a week or a quarter, whether the cause is understood, or whether anything else in the plan is affected. A useful update says what has happened, what is still open, and what it affects:

“The CDMO has completed the batch and delivered the batch record. A deviation is under investigation, and QA release depends on its outcome. We can share a manufacturing progress update in June. We will reassess the expected release date once [specific data] are available, and send an updated forecast on [date].”

The last date is a promise to update, not a promise that the problem will be solved by then. If the release date is still uncertain at that point, the next update should say what is still unknown and when it will be assessed again.

Then follow the delay through the rest of the plan. If release moves by a month, trial start may move with it, and so may the point at which the company expected to show investors clinical progress. That can change cash needs and runway. Holding the original fundraising timeline while the dates underneath it move is how a delay turns into a surprise.

The company controls its own work. It does not control when an investor finishes diligence or makes a decision. A plan that assumes the financing will close immediately after the milestone has no room for either delay.

To see how stage timing and historical success rates add up across a development plan, you can test your own assumptions in the free Milestone Scenario Planner.

Before the date goes into the deck

Most of what I have described comes down to one habit. Before a date goes into the deck, ask the people producing, reviewing, and using the material what they expect to have on that day. Ask them separately, in their own words.

If their answers match, you have a shared definition of the milestone. You still need to check whether the work and dependencies support the date.

If they differ, you have found a gap while there is still time to close it, and that is much cheaper than finding it in front of an investor.

Editorial note: Examples are drawn from the author’s own experience and have been anonymized.