The Schedule Is the Work

A twelve-month stability pull takes twelve months. A contract manufacturer who has reserved you a registration batch slot will give it to somebody else if you are late to it. A regulator schedules your meeting, and the review clock starts when the agency says it starts, not when you would like it to. Everything else in a drug development program flexes around a small number of fixed points, which means the plan is not a list of work. It is a network with a critical path running through it, and if you cannot compute that path you are not managing the program, you are describing it.

I have spent my career in CMC program management across small molecules, biologics and cell therapy, including leading BLA and pre-license inspection readiness. That work means coordinating dozens of concurrent projects across more than a dozen functions, usually without a single one of those people reporting to me. In that job the schedule is the only authority you have. When it is wrong, everyone finds out at the gate review. When it is invisible, you have nothing at all.

So I have opinions about scheduling tools, and most of them are complaints. What follows is the general case, which applies to anyone whose plan has hard external dates in it, told through the specific case I know best.

The dates that do not move

Every project management textbook opens with the triangle: scope, cost, time, pick two. It is a useful lie. In regulated drug development, time is frequently the constraint you cannot trade, because the thing consuming it is not effort. It is elapsed calendar, sitting in a chamber, or it is somebody else’s calendar entirely.

Notice what these have in common. None of them respond to resourcing. You cannot put two people on a stability study and get a six-month pull. This is the specific thing that breaks the mental model most work-management software is built on, which assumes that a task is a bucket of effort and that the schedule is an emergent property of who is free.

In a program built around fixed external dates, the question is never “who is available.” It is “what does this push, and does it reach the filing.”The only question that matters

A plan is a network, not a list

The critical path method is not new and not controversial. It dates to the late 1950s, it is taught in every project management curriculum, and the mathematics fits on a page. You build a directed graph of activities and dependencies. You run a forward pass to get the earliest each activity can start and finish. You run a backward pass from the required end date to get the latest each can start and finish without delaying the project. The difference between the two is total float. The chain of activities carrying the least float, which in a plan with no imposed end date means zero, is the critical path, and delaying any activity on it delays the end.

That is the whole idea, and everything useful follows from it. Total float tells you where the slack actually lives, which is almost never where the loudest person thinks it is. Free float tells you how far an activity can slip before it disturbs its immediate successor rather than the project. The critical path tells you which of your forty open items deserve your Thursday afternoon.

Here is the part that matters for CMC. A program of this shape has long chains of activities that are individually unremarkable and collectively decisive. Analytical method qualification gates the release of the registration batches, which gate the start of the registration stability study, whose twelve-month pull gates the stability data package, which gates the module that gates the filing. Nothing in that chain is dramatic. Every link is ordinary work. But a two-week slip at the front of it emerges, unchanged, as a two-week slip at the filing, and the only way to see that before it happens is to compute it.

Five places the tools let pharma down

I want to be fair to the software. The modern work-management platforms are genuinely good at the thing they were designed for, which is coordinating knowledge work where the constraint is attention and the deadlines are soft. That is a real problem and they solve it well. It is just not this problem.

1. They draw the schedule instead of computing it

Most popular platforms offer a Gantt view, and in most of them the bars are decorations. There is no forward pass, no backward pass, no total float, no critical path that updates. Dependencies exist as arrows that constrain nothing, or as a rule that nudges a successor when you drag a predecessor and then stops. Move a task and the downstream network does not know. The chart is a picture of the dates someone typed in, which means it is a record of intent rather than a model of consequence, and it is right exactly until the first thing goes wrong.

2. They do not speak pharma time

A plan that models reality needs working-time calendars, so a fourteen-day activity that runs over the winter shutdown lands where it really lands. It needs the constraint types that pin an activity to an external date you do not control, and it needs them to behave correctly when the network pushes against them. It needs start-to-start links with lag, because stability sample pulls overlap the study rather than following it, and a finish-to-start link is simply the wrong shape. It needs durations that can run on the calendar rather than on working hours, because a chamber does not observe Thanksgiving.

Where a tool cannot express those things, planners do the only thing left and type the dates in by hand. That works, briefly. Then the plan stops being a model and becomes a spreadsheet of assertions, and nobody can tell which dates were computed and which were wished for.

3. Risk lives in a different file

Every program keeps a risk register. Very few of those registers are connected to the schedule. A nitrosamine risk in the drug substance route gets scored in a spreadsheet, discussed at the risk review, assigned an owner, and never touches a date. Meanwhile the plan proceeds as though the risk does not exist, because as far as the plan is concerned, it does not.

This is not a software failure alone, it is an organisational one that software has been happy to accommodate. Quality risk management under ICH Q9(R1) asks you to identify hazards, then analyse, evaluate and control the risk, and to feed the result back into the lifecycle. If the control never reaches the schedule, the loop is open. The register and the Gantt drift apart quietly for two quarters and then collide at the gate review, in public.

4. They give one date when leadership needs a confidence level

“We file on 10 February” is not a forecast. It is the date you get if nothing goes wrong, which in CMC development is the one outcome you can confidently rule out. It is a single sample from a distribution, presented as though it were the distribution.

What a steering committee actually needs is two numbers: the date you hit about half the time, and the date you can commit to. Those are different dates, often by months, and the gap between them is the single most useful piece of information the schedule contains, because it is a measure of how much uncertainty the program is carrying. Tools that can produce it exist, but they are specialist add-ons, priced and packaged for enterprise risk teams, and they are not sitting on the desk of the CMC lead building Thursday’s slides.

5. The real plan dies in a slide

The scheduling engines that do compute dates properly tend to be heavyweight, Windows-bound and effectively single-seat. So the real schedule lives on one planner’s laptop, and everyone else sees a screenshot pasted into a deck. The deck is rebuilt by hand every week. It is stale before it is presented, it cannot be interrogated in the room, and the one question the room always asks, what if this slips, can only be answered by someone who is not there.

One date, when leadership needs a confidence level

This one deserves its own section, because it is where the gap between what pharma programs need and what pharma programs get is widest, and because the fix is well understood everywhere except here.

A schedule simulation works like this. Instead of a single duration, each activity carries a range: optimistic, most likely, pessimistic, with a distribution over them. You run the network a few thousand times, sampling a duration for every activity on each pass, and you record the finish date each time. What comes back is not a date but a curve. The date at the fiftieth percentile is the one you will beat half the time. The date at the eightieth is the one you can put in front of a board without crossing your fingers.

P50

the honest internal target, beaten half the time

P80

the date you commit to externally

P50–P80

the gap, which is the program’s uncertainty made visible

Two by-products of that run are worth more than the percentiles. The first is the criticality index: how often each activity landed on the critical path across all those iterations. A deterministic critical path is a single answer to a question with a probabilistic shape, and it can be misleading, because a near-critical chain with two days of float and enormous variance is far more dangerous than a critical chain with no float and no variance at all. The criticality index finds those. The second is the tornado, which ranks activities by how strongly their duration correlates with the finish date, and therefore tells you where attention actually buys you time.

That last point is the one I would defend hardest. Most program acceleration effort is spent on whatever is loudest, latest or most embarrassing. A tornado chart is a list, in order, of the only places where going faster changes the outcome. Some of them will be obvious. The value is not in the surprises, it is in having the obvious thing stated by the plan rather than asserted by the most senior person in the room.

What a scheduler has to do to earn the name

Independent of any product, here is the specification I would hold a scheduling tool to for this kind of work. It is a useful checklist whether you are buying something, or deciding whether the thing you already have is doing the job.

Nothing on that list is exotic. Most of it was solved decades ago in construction, defence and heavy engineering, which have the same problem shape: long chains, hard external dates, expensive slips. Pharmaceutical development inherited the problem and, for the most part, not the tooling.

What we are building

Full disclosure, because the rest of this section is about my own product and you should read it with that in mind. Everything above stands on its own and applies whatever you use.

FractalFlow is a professional project scheduler for Mac, iPhone and iPad, from Rizkin Labs. It starts from the premise in the title: the schedule is the work, so the schedule should be computed, interrogable, and in the hands of everyone who has to answer for it.

It is not a pharma-only tool and it is not a clone of anything. It is a general scheduler that happens to have been tested against the hardest schedules I know, on the theory that if it survives a CMC program it will survive yours.

A worked program, end of Phase 2 to submission

To have something concrete to test against, we built a fictional small-molecule program: NWP-417, an oral tablet going from the end of Phase 2 through submission and into pre-approval inspection readiness. Drug substance, drug product, analytical, quality and supply, Module 3, process performance qualification. Seven owners. Partway through, the plan takes a nitrosamine finding in the route that adds fourteen days to the purge study, which is exactly the sort of ordinary, unglamorous event this whole argument is about.

Two things are worth drawing out of that table. The first is the distance between 4 May and 29 August. Nothing went wrong to produce it. It is the same plan, with the same activities, run with honest ranges instead of single-point estimates, and the four-month gap is the uncertainty that was always in the program and was previously just not written down anywhere.

The second is the tornado. Any experienced CMC lead would have guessed that twelve-month stability tops that list, and they would have been right, and that is precisely the point. The value is not that the tool knows something you do not. It is that the plan now says it too, with a number attached, in a form you can take into the room instead of an argument you have to win on seniority.

The difference between an experienced instinct and a defensible plan is not the conclusion. It is whether anyone else can check it.On why the obvious answer still needs computing

What to do about it on Monday

Whatever you use, and whether or not it is ours, three habits do most of the work.

1. Find your fixed points and write them down as constraints, not as tasks. The agency meeting, the CDMO slot, the site shutdown, the stability pull. Everything else in the plan should be positioned relative to those, and the plan should tell you loudly when the network pushes into one.
2. Put a range on the ten activities that matter. You do not need ranges on all four hundred. Put optimistic, likely and pessimistic on the long-lead chain, run the simulation, and present the P50 and the P80 rather than the single date. Expect the first conversation about the gap to be uncomfortable and every subsequent one to be easier.
3. Make the risk register move a date or delete it. If a scored risk cannot be connected to an activity and a schedule impact, either it is not a schedule risk, in which case say so, or it is not being managed. Both are worth knowing. This is the same discipline as running the program as a pull system: the artefact has to do work, or it is overhead.

The broader point is not really about software. It is that a schedule is either a model of how the program actually behaves, in which case it deserves the effort of being right, or it is a communication artefact, in which case stop pretending it forecasts anything. The two jobs are both legitimate. Doing the second while believing you are doing the first is how programs arrive at the gate review with a date nobody has checked since the last reorganisation.

FractalFlow is coming to the App Store. If the argument above is familiar, follow Rizkin Labs for the launch, or get in touch, particularly if you plan programs of this shape and want to break it before everyone else does.