A clinical trials digitisation project that began with an inherited requirements document, hit a structural wall mid-engagement, and had to be rebuilt from scratch — under budget pressure, with client trust on the line.
A healthcare and research organisation running clinical trials had operated on paper-based workflows for years — data capture, cross-role coordination, and trial progress tracking all handled by physical documentation that was slow, hard to audit, and prone to gaps.
A Business Analyst was brought in to bridge clinical operations and the development team: map the workflows, gather requirements, and produce the documentation the system would be built and tested from. The client arrived with a draft requirements document already written. The expectation was clear — use it as the foundation and move quickly.
We already know what we need. We've written it down. We just need someone to turn it into a system.
— Client stakeholder, initial briefingThat assumption, accepted too early, became the central problem.
Analysis began against the client's draft BRD. Stakeholder sessions were held, primarily through a Senior Lab Technician acting as the operational intermediary. Requirements were expanded, formalised, and structured into a working set. The document grew. On the surface, the engagement was progressing.
What wasn't visible yet: the draft had been written from memory and assumption rather than observed workflow reality. It described how people believed the process worked — not how it actually did. That distinction didn't surface until the work reached development.
The feedback was direct: the documentation couldn't be built from. Workflow logic didn't translate to system architecture. Requirements contradicted each other in places, left gaps in others, and reflected stakeholder assumptions rather than ground-truth operations. The document needed to be rewritten — not patched.
Before any reset could happen, there was a harder problem: the client had written the original document and believed it was sound. Telling them it couldn't be used — and that fixing it would cost more time and money — was a significant moment in the relationship.
A clear account of what had been done, what the development review had found, and what a rebuild would require was put in front of the client directly. The reset wasn't framed as a failure — it was framed as the point where assumptions had been tested and real requirements work could finally begin.
The client agreed to proceed. Keeping that trust came down to one thing: being specific. Clients can absorb difficult news. What erodes trust is vagueness about what went wrong and why.
With the inherited document set aside, the work restarted with a different posture. Every workflow was treated as unknown until directly observed or confirmed. Where the Lab Technician intermediary remained the primary contact, their input was treated as a starting point — not a sign-off.
A gap analysis between the original BRD and the re-mapped workflows revealed the scale of the problem: data handoff points between roles, exception handling in non-standard trial scenarios, and audit trail requirements had all been either misrepresented or missing entirely. The rebuild addressed each of these from first principles.
Requirements were reviewed iteratively with stakeholders as they were developed rather than presented as a completed document at the end. This caught misalignments early and kept the client close to the work throughout.
The rebuilt BRD, user stories, and acceptance criteria moved into development and testing without the structural problems that had stopped the first pass. The system was built and validated against requirements that reflected how the workflows actually operated.
The single thing this project changed about how I approach inherited documentation: a client-provided document is a hypothesis, not a brief. The first thing it needs is a structured challenge — not expansion.