NPO & Social Impact · Systems & Operational Improvement
Management reporting had become a separate administrative exercise
Each programme looked workable on its own — a spreadsheet for accommodation, case notes for psychosocial work, a register for training. The difficulty was the cross-programme picture: the same beneficiary counted differently in different places, definitions drifting between teams, and every monthly statistic requiring reconciliation before anyone could trust it.
- 8
- programme areas unified
- 19
- users in scoped environment
- 1
- governed central record
- 4
- capture channels designed
Proof context: A multi-programme care organisation
Engagement type
A retained, chargeable professional-services mandate — not contingency work. KuTh’s role was to own the problem-solving process: define the operating requirement, structure the solution, bring together the specialist capability needed, and oversee delivery through testing and handover. Technology was a tool used to reach the result, not the definition of the service.
The situation
Why manual programme statistics become difficult at scale
Scroll table sideways →
| Characteristic | Operational consequence |
|---|---|
| Multiple local registers | The same person or household can be counted differently across programmes or sites |
| Free-text definitions | Two teams use the same label to mean different things, or different labels for the same service |
| End-of-month collation | Staff re-key or merge data after delivery, adding delay and error opportunity |
| Version control | Email attachments and copied spreadsheets make the approved dataset hard to identify |
| Weak longitudinal view | A beneficiary’s journey across accommodation, transport, psychosocial and practical support becomes hard to see |
| Reporting burden | Funder, board and management reports need repeated manual aggregation instead of reusable logic |
| Privacy risk | Sensitive beneficiary information spreads into files and channels never designed for controlled access |
Each programme can look perfectly workable in isolation. The difficulty emerges the moment the organisation needs a reliable cross-programme picture.
What KuTh did
Architecture first, automation second
- Mapped the process before designing anything. The manual workflow, reporting needs, hand-offs and responsibilities were mapped to identify where the process itself had to change — not only where a system was missing.
- Defined shared data architecture. Entities, fields, identifiers and relationships were designed so information could roll up without being rebuilt each cycle, across eight programme areas.
- Treated security as a design workstream. In an environment holding information about children, health circumstances, family conditions and bereavement, access was designed around role, purpose and sensitivity — not configured afterwards as an IT setting.
- Put capture close to the work. Four capture options were designed into the architecture — spreadsheets and forms, ODK, Kobo-type field tools and direct entry — so staff working in hospitals, community settings and outreach locations could record at the point of service, including offline.
- Designed reporting backwards from the question. Starting from what management, boards and funders actually ask, then working back to the source event and the capture requirement — rather than collecting whatever a form had room for.
The result
What changed in the operating model
Scroll table sideways →
| Result | Operational meaning |
|---|---|
| One source of record | Operational information governed centrally rather than dispersed across uncontrolled local files and versions |
| Common definitions | Shared architecture reduces the risk of consolidated statistics combining unlike measures |
| Role-aware access | Sensitive information managed according to user role and purpose |
| Repeatable reporting | Management information generated from structured records rather than rebuilt every cycle |
| Controlled implementation | Sandbox, user acceptance testing and training expose process exceptions before production |
| Scalable architecture | Additional workflows, forms, programmes and integrations can be added to a defined structure |
The hidden work
Technology does not fix inconsistent definitions
Before a field is created, the organisation has to decide what it means, who owns it, when it is captured and how it will be used. Each indicator needs a clear name, an operational definition of what counts and what does not, a unit of count, a source record, a reporting frequency, a responsible owner and a validation rule.
“Accommodation supported” is ambiguous. “Bed nights provided” and “unique beneficiaries accommodated” answer different management questions and should never be treated as interchangeable. That definitional work is what makes a consolidated statistic trustworthy, and it is invisible in the final report.
Evidence and publication boundary
This mandate produced an operating result, not a financial one, and no cost saving is claimed. The measures on the data sheet — reporting lead time, data completeness, rework hours, management visibility — are offered as measures an organisation should track. They are not presented as results achieved here, because the source record contains no before-and-after values for them.
Client identity is withheld. Platform and tool names are retained because they describe the architecture rather than identify the organisation. The delivery pre-dates the current platform generation; the design principle stated in the source still holds — capture as close to the work as practical, govern the authoritative record centrally, and make reporting a repeatable output of the operating process.
Supporting documents