CLIENT CONTEXT
Over a century of child protection work. A back-office that hadn’t kept pace with it.
Cape Town Child Welfare Society (CTCW) has been protecting vulnerable children since 1908. Today, the organisation operates across five intake offices in the Cape Peninsula, takes on approximately 40 new cases every day, and has helped more than a million children emerge from abuse, neglect, poverty, and homelessness. The scale and longevity of the organisation is not in question.
The operational infrastructure was a different story. CTCW was running its entire case management operation on paper files and Microsoft Excel spreadsheets. For an organisation handling some of the most legally sensitive, time-critical casework in the country, this created compounding risk. Cases were difficult to track across units. Administrative burden was consuming time that social workers needed to spend with the families they served.
With strict legislative deadlines tied to the Children’s Act 38 of 2005, some measured in days, missed timelines weren’t just an operational problem. They were a compliance risk with direct legal consequences.
CTCW knew a digital case management system was needed. What they did not yet have was a clear picture of what that system should actually do.
THE CHALLENGE
The complexity wasn’t in the technology. It was in the organisation itself.
This was not a case of finding the right software and configuring it. Before any development could begin, someone needed to understand CTCW’s operations in enough detail to specify them precisely. That meant mapping every workflow, every actor, every permission boundary, and every legislative deadline across an organisation that had never had those things documented in one place. The scope of that discovery work was not obvious until Realm was inside it.
The discovery process also revealed something CTCW’s own team had not previously had: a single, connected picture of how the organisation actually operated. That absence of shared documentation was itself a contributing factor to the administrative burden they were trying to address.
REALM’S APPROACH
The deliverable was a specification document. The real work was making a complex organisation legible to itself.
Realm led a structured discovery process built around stakeholder workshops and deep process analysis sessions with the CTCW team. The goal was not to collect a wish list of features. It was to map every workflow end-to-end, understand the relationships between them, and produce a System Requirements Specification precise enough that CTCW could hand it to a development vendor with confidence.
Stakeholder Workshops and Process Mapping
Eight core business processes were mapped in full, each with its associated notifications, alerts, actors, permission levels, and legislative deadlines documented explicitly. Five user roles were defined with distinct permission structures aligned to CTCW’s organisational hierarchy. The workshops covered the full operational picture, not as separate modules but as a connected system with dependencies between workflows.
Phased Development Roadmap
Rather than specifying everything as a single build, Realm structured the requirements across development phases. Phase 1 covered core case management, search, reporting, and user access. Phase 2 added foster care and adoption management, region mapping, and performance analytics. A Phase 3 features wishlist included AI-assisted decision support for social workers.
A specification is only useful if a vendor can build from it
The SRS had to be precise enough to go directly to a development vendor without further interpretation. That meant every workflow had to be documented to a level of detail that made implementation decisions clear, not just described. Ambiguity at this stage translates directly into scope creep, delay, and cost overrun during development.
Reporting and Compliance Requirements
Seven report types were defined, covering case lists, court rolls, transfer payment agreements, child death reviews, and ministerial inquiries. Many of these were aligned to government standards and court requirements, which meant the specification had to reflect those external frameworks accurately, not just CTCW’s internal preferences.
Non-Functional Requirements
The SRS also covered security requirements aligned to the POPI Act, usability, cloud infrastructure, data migration from paper and Excel records, and training needs. These were treated as first-class requirements, not an afterthought.

THE OUTCOME
CTCW left the engagement with a vendor-ready blueprint, and a clearer understanding of their own organisation.
The System Requirements Specification gave CTCW something precise and actionable: a document they could take directly to a development vendor to begin building. But the structural value of the engagement went beyond the document itself. For many CTCW team members, the process of mapping and documenting their workflows was the first time the full operational picture had been visible in one place. That clarity became the basis for internal alignment and strategic planning.
What the specification made possible
- A development vendor can now build to a defined scope, reducing the risk of misalignment, scope creep, and cost overrun
- Legislative deadlines under the Children’s Act are built into the system as structural requirements, not reliant on individual staff knowledge
- User roles and permission structures are defined, meaning the system will reflect CTCW’s organisational hierarchy from day one
- A phased roadmap means CTCW can begin with core case management and extend the system incrementally as capacity and funding allow
- Social worker time previously consumed by administrative burden has a clear path to being redirected toward direct casework
“The Realm Digital team was highly professional, easy to work with, and patient with us throughout the project.”
– Penny Whitaker, Director, Cape Town Child Welfare Society
WHAT THIS TELLS YOU ABOUT HOW WE WORK
Getting the brief right is sometimes the entire job.
CTCW did not need Realm to build a system. They needed Realm to define what the system should do, precisely enough that someone else could build it without ambiguity. That is a different kind of engagement, and it requires a different kind of discipline. The value is not in the output alone. It is in the rigour of the process that produced it.
On this project, that meant running structured workshops across a large, multi-unit organisation, mapping workflows that had never been formally documented, and translating operational complexity into specification language that a development vendor could act on directly. It also meant being patient with an organisation working through its own processes in real time, many for the first time.
