From spreadsheets to a CTMS: the adoption problem, not the feature problem
Replacing spreadsheets is easy to build and hard to make people actually do. Launched publicly at the Clinical Trials Summit of Pakistan 2026.
Spreadsheets are not the enemy
Trial management ran on spreadsheets: site contacts, visit schedules, enrolment tracking, monitoring plans, action items, milestone dates. One workbook per study, sometimes several, usually emailed.
It is tempting to treat that as obvious failure. It is not. Spreadsheets won because they are free, instant, infinitely flexible and require nobody's permission. Any replacement has to be better at the specific jobs where they fail, without being slower at the daily jobs where they work.
That reframing decided the whole build. The question was never "what does a CTMS do." It was "what does a spreadsheet actually cost us, and will anyone switch."
Where spreadsheets were genuinely costing us
No single version of the truth. Three people editing three copies, with the real state of a study living in whoever's inbox was most recent.
No visibility without asking. Leadership could not see portfolio status without someone compiling it, which meant status reporting was a weekly manual job and always slightly out of date.
No accountability trail. Who changed the enrolment target, when, and why, was unanswerable.
No connection to the data. The study existed twice, once in the EDC and once in a workbook, and the two drifted.
Those four, and only those four, were the brief.
The adoption problem
A CTMS that is more work than a spreadsheet for daily entry will lose, regardless of how good the reporting is. People do not adopt systems because the system is correct, they adopt them because the system is easier than the thing they are already doing.
So the design priorities were ordered against that. Entry had to be fast and forgiving. The system had to pull what it already knew from the EDC rather than asking someone to retype it. Reporting had to be automatic, so the first thing the team got back was the weekly status job disappearing from their plate. Nothing was mandatory on day one that was not mandatory in the spreadsheet.
The migration itself ran study by study rather than all at once, with the spreadsheet kept alive in parallel until the team stopped opening it. Nobody was told to stop using spreadsheets. They stopped on their own, which is the only version of that transition that holds.
Launching in public
The module was demonstrated live at the Clinical Trials Summit of Pakistan 2026, in front of an industry audience convened with NUMS, Aga Khan University and the Drug Regulatory Authority of Pakistan.
A public launch date is a product management instrument, not just a marketing event. It forced scope decisions that would otherwise have stayed open, because a date you cannot move converts "we should also do" into "we will do that next." Several features were deliberately cut to protect it. All of them shipped later, and none of them were missed on the day.
What I would tell anyone doing this
Do not sell the system on its features. Find the one recurring job your team hates, make that job disappear first, and let adoption follow the relief.
Inside the platform
Inside this workflow
Real interfaces with demonstration data. Select a screen for a closer look.
The study at a glance.
Sites, queries and study progress in one operational view.
A clearer view of every site.
Organise study sites, investigators and site identifiers.