After nineteen years at the bench and three years watching research-IT projects from the other side of the table, one pattern becomes impossible to ignore. Well-funded projects. Capable teams. Modern platforms. And still — scientists who don’t end up using the tools built for them.
The problem usually isn’t technology. It’s translation.
The failure mode is remarkably consistent. A legitimate need is identified within a research organization. Budget is approved. A delivery team is assembled. Requirements are gathered — often in a handful of meetings with a few scientists who may or may not represent the broader group. Then the build begins.
Months later the platform launches. Adoption is thin. Scientists keep their workarounds. The project is quietly logged as a partial success, the lessons go unwritten, and the cycle resets with the next initiative.
The language gap nobody budgets for
The breakdown isn’t a process failure or a technology failure. It’s a language failure, and it starts at the requirements stage.
Scientists think in assays, compound series, biological targets, and experimental workflows. They describe what they need in a shorthand that is precise inside the domain and close to opaque outside it. Delivery teams think in data models, interfaces, user stories, and sprints. Both groups are highly capable. Neither speaks the other’s language fluently.
What survives the handoff is the big, explicit requirements. What gets lost are the unstated assumptions — the things every scientist knows and would never think to say out loud, because the context seems obvious. It isn’t.
Three places projects fall apart
- Requirements gathering that skips the daily user. A few senior scientists in a conference room don’t represent the full range of workflows a tool has to support. The person who would use the system every day is rarely the person in the room.
- Adoption treated as a launch-day problem. Planning for adoption that starts at launch starts too late. Scientists have habits built around existing tools, and the switching cost is higher than most plans assume.
- No one accountable for the gap itself. IT has a project owner. The business has a sponsor. But who owns the translation layer between them? In a lot of organizations the honest answer is no one — or everyone, which comes to the same thing.
What changes the outcome
The projects that break the cycle tend to have one thing in common: someone at the table has real fluency in both domains. Not a courier passing messages, and not someone working from a glossary — someone who has actually done the science, knows what a given system means for a scientist’s daily work, and can sit in a review and catch the moment a delivered feature satisfies the written requirement but misses the real need.
That person doesn’t make the gap disappear. They make it visible — early enough to close it before it becomes a failed launch.
Christian Clarke spent 19 years as a medicinal chemist and 3 years as a Business Relationship Manager within the Research IT organization of a major pharmaceutical company. Through Clarke Discovery Bridge, LLC he offers fractional medicinal chemistry consulting and fractional scientific-advisor support for consulting firms running translational projects.