| PROJECT SPOTLIGHT | Three hard-won lessons from the coalface of clinical research IT.
There is a particular kind of organisational pain that most senior IT leaders will recognise immediately, even if they have never worked in pharmaceuticals or clinical research. It is the pain of systems that were chosen in isolation, implemented in silos, and left to sit alongside each other without ever truly connecting. The result is a patchwork of platforms, a team of people manually bridging the gaps, and a growing list of things the business cannot do; not because the technology does not exist, but because nobody managed the integration properly from the start.
We have seen this pattern repeat across sectors. But it is in clinical research and pharmaceutical operations where the consequences of getting it wrong are felt most acutely, where regulatory compliance, global nurse coordination, and multi-million-pound business development pipelines all depend on the right data being in the right place at the right time.
Over recent years, Stoneseed has worked with several organisations in this space, providing PMaaS resources across a range of complex IT delivery challenges. What follows are three practical lessons drawn from that experience; lessons that apply well beyond pharma and life sciences.
Lesson One: Integration Is Not an Afterthought – It Is the Project
One of the most significant projects we supported in this sector was a £500k Resource Management Platform build for a clinical research organisation. The brief was ambitious: select and design a bespoke platform using Salesforce, roll it out to 50 back-office staff and 450 global nurses, and make it work. The selection process alone involved shortlisting 30 suppliers and running a rigorous full tender process, followed by a structured proof of concept with the preferred partner.
But here is the thing most organisations underestimate: selecting the right platform was not the hardest part. Making it connect with everything else was.
The project required deep collaboration between the project manager, solution architects, and the CIO to develop system integrations across the organisation. The new Salesforce platform had to talk fluently to the existing LMS, HR system, and Finance system. None of those integrations were incidental. Each one represented a dependency that, if mishandled, would have left the platform functionally incomplete, a technically delivered project that still failed the business.
The lesson for any IT leader overseeing a platform selection or implementation is straightforward: start with the integration map, not the feature list. What does this system need to receive from, and send to, your existing estate? Who owns those adjacent systems? What are the data standards, the API constraints, the timing dependencies? These questions need answers before the contract is signed, not after go-live.
Connectivity defines value. A well-chosen system that sits in isolation will always deliver a fraction of what it could.
Lesson Two: Governance Has to Match the Pace of the Problem
Separately, we supported the same organisation on a £150k Salesforce Sales Cloud enhancement project; improving and upgrading an existing instance to help the business manage a caseload of £80m in Business Development opportunities. This was not a greenfield build. It was a live platform, actively used by teams chasing real commercial deals, that needed meaningful improvement without disruption.
The approach was deliberately agile. Four sprints of focused improvements, each one scoped around user stories that had been carefully captured, mapped, and prioritised against business expectations. Third-party suppliers were managed throughout to ensure they met both quality standards and commercial commitments.
The reason this worked was not the methodology itself, it was the decision to match the methodology to the problem. Agile was right here because the business needed to see incremental value quickly and could not afford to pause its BD operation for a lengthy waterfall cycle. Had a rigid governance model been imposed, long sign-off chains, fixed scope, extended planning phases; the project would have stalled precisely when the business needed momentum.
Too many IT functions default to a single delivery framework regardless of context. The better question is always: what does this specific challenge actually require? Sometimes that is structured waterfall discipline. Sometimes it is sprint-based agility. Often, particularly on infrastructure versus software projects, as we saw in the programme office review work we have done with pharmaceutical clients, it is both, running in parallel across different workstreams.
Governance that does not serve the pace of the problem is not governance. It is friction.
Lesson Three: Vendor Selection Is a Discipline, Not a Meeting
Perhaps the most consistent theme across our clinical research and pharmaceutical work has been the quality of vendor selection. Or more precisely, the gap between organisations that treat it as a discipline and those that treat it as a box-ticking exercise.
Across multiple engagements; from the selection of a Greenhouse ATS system delivered within five months, to the structured review and selection of a new Clinical Trials Management System; we have seen what rigorous selection looks like in practice. It involves defining business requirements clearly before approaching the market. It involves producing a formal RFI, managing the assessment process, and scoring suppliers against weighted criteria using tools like the Pugh Matrix. It involves defining the selection business scenarios; the real-world use cases that a system must handle; and testing suppliers against those scenarios rather than against their own marketing claims.
The Greenhouse ATS implementation is a useful example of what rigorous selection unlocks. Delivered in five months, to time and to budget, it required the project manager to coordinate regular working groups, manage planning and risk sessions, report to the Senior Management Team and sponsors throughout, and then oversee the rollout of the integrated onboarding application from the supplier. That kind of delivery only happens when the right supplier has been chosen in the first place.
Poor vendor selection does not just slow delivery. It poisons the entire project lifecycle. The wrong supplier, even a technically capable one, will cost you more in relationship management, scope creep, and quality remediation than the original contract was ever worth. Structured evaluation protects against that. It separates the supplier who can do the job from the one who is simply best at pitching for it.
Beyond Pharma: Why These Lessons Travel
Clinical research is a demanding IT environment. Regulatory requirements are exacting, the user base is frequently distributed and mobile, and the systems that support operations, from resource scheduling to clinical trials management to nurse onboarding, are genuinely mission-critical. Mistakes have consequences.
But the underlying challenges are not unique to this sector. The IT Director navigating an ERP upgrade in manufacturing, the CIO overseeing a SaaS consolidation in financial services, the Head of IT managing a digital transformation in higher education, they are all wrestling with versions of the same three problems. How do we make our systems work together properly? How do we govern delivery at the right pace? How do we choose suppliers who will actually deliver?
The organisations that answer those questions well tend to share one thing: they bring the right project capability in at the right time, rather than stretching internal resources beyond its bandwidth or leaving critical decisions to chance.
That is exactly what PMaaS (Project Management as a Service) is designed to do. Not to replace your internal team, but to extend it with experienced project professionals who have navigated exactly these kinds of challenges before, often many times over.
A Question Worth Sitting With
As you look at your current IT project portfolio, consider where the friction actually lives. Is it in the choice of systems, or in how well those systems connect? Is it in the methodology being used, or in whether that methodology actually fits the pace the business needs? Is it in the suppliers you have selected, or in how rigorously you selected them?
The answers are rarely comfortable. But they are almost always useful.
If you would like to explore how Stoneseed’s PMaaS model could support your next IT project or programme, we would be happy to have that conversation.
More about Project Management as a Service from Stoneseed