The Operational Cost of “We’ll Add That Later”

Why useful RTSM functionality often gets deferred, and why the real cost tends to appear after go-live.

There is a familiar moment in study planning when a good idea starts to slip.

A capability is discussed. Everyone agrees it would help. It could reduce manual effort, strengthen control, improve visibility, or make life easier once the study is live.

Then the mood changes.

Timelines tighten. Go-live gets closer. The conversation narrows to what feels essential for launch. And the feature that sounded valuable ten minutes earlier suddenly gets a new label: We’ll add that later.

A familiar moment in study planning

It is one of the most understandable phrases in clinical trial delivery.

It is also one of the most expensive.

Not always immediately. That is the catch.

A study can launch successfully and still inherit avoidable friction for months afterwards. Sites feel it in awkward workflows. Study teams feel it in manual workarounds. Supply teams feel it when change becomes harder to manage cleanly than it needed to be.

What looked like a sensible scope decision during a build can become an operational burden once the study is live.

A study can launch successfully and still inherit avoidable friction for months afterwards.

Why “later” is rarely neutral

In many cases, the functionality being deferred is not ambitious or experimental. It is practical. It may support traceability, improve accountability design, enable smoother access, or help teams respond more effectively to operational change.

The issue is not that the value is hard to see. The issue is that the value often arrives later than the implementation effort.

That timing gap shapes behavior.

When a team is pushing towards go-live, it is natural to focus on what feels essential for day one. If a capability requires extra alignment, more process definition, technical coordination, or broader sponsor readiness, it can quickly start to feel like something that can wait.

And that is how useful functionality starts drifting into the future.

The problem is that “later” is rarely neutral.

What gets postponed is not only the feature itself. It is the operational benefit that feature was meant to provide. The decision is no longer just about whether something is included before launch. It is also about whether teams will end up paying for its absence after launch.

The question teams should ask instead

A study build may take a few months. The study itself may run for years. Teams live with those design choices far longer than they spend making them.

A capability that feels optional during a build can become highly valuable once the study is live and real-world pressure starts to show up.

That is why the decision-making lens matters.

Too many RTSM choices are still framed around a narrow question: is this required to get the study live?

It is not a bad question. It is just incomplete.

That is the more useful test.

It pushes the conversation beyond immediate launch pressure and towards long-term execution. It forces teams to think not only about the build, but also about maintenance, oversight, continuity, and what the study team is likely to wish they had six months later.

What this means in practice

Of course, not every capability belongs in every study. No one benefits from adding complexity for the sake of it. The goal is not to turn every build into a wish list.

The goal is to make more deliberate decisions about what is included, what is deferred, and what those choices are likely to cost later.

That takes a slightly different kind of discipline.

It means asking sharper questions earlier. What is likely to matter once the study is live, even if the pain is not visible yet? Which capabilities depend on broader readiness and therefore need earlier planning, not later rescue? Where is the bigger risk, overbuilding, or leaving the study too rigid to adapt cleanly?

Those are not always the fastest questions. They are often the right ones.

Sponsor type can shape the pattern, but it does not remove it. Smaller sponsors may be open to innovation but lack the infrastructure to carry certain decisions through. Larger organizations may have the scale and governance to support more advanced functionality, but slower alignment across teams can make implementation harder. In both cases, the issue is rarely a lack of interest. It is the gap between recognizing value and getting that value into live execution.

The cost is often measured later

So yes, sometimes “we’ll add that later” is the right call.

But sometimes it is simply a polite way of postponing a decision that matters more than it seems to.

And in RTSM, the true cost of that decision is rarely measured at go-live.

It is measured later, when the study is live, the pressure is real, and the missing capability would finally have earned its place.

Read the full white paper: The Innovation Implementation Gap