NPO & Social Impact · Systems & Operational Improvement
A system that counts only people understates intensity; one that counts only services overstates reach
Neither error shows up in the resulting report, which is what makes it dangerous for an organisation reporting to funders. The model needs a unique-person dimension and a service-interaction layer held separately.
- 13.5%
- negotiated cut, average estimate
- 23.4%
- on the low-case scenario
- 16.7%
- on the high-case scenario
- 7
- cost components itemised separately
Proof context: A multi-programme organisation collating service statistics manually
The situation
Collecting a great deal, able to report very little
Organisations collect large volumes of service and beneficiary information without a reliable way to consolidate it, analyse it, or turn it into management information. Different sites record the same activity differently. Reporting depends on spreadsheets and manual collation. The system that exists does not reflect the questions management actually needs answered.
The sequence matters here. KuTh defined the reporting requirement first, translated it into a usable data architecture, tested the commercial and technical options, and only then structured a solution — around controlled capture, centralised storage, user accountability and repeatable reporting.
The requirement
What the solution had to do
- Capture people served and services delivered in a consistent structure, with demographic, geographic, programme and service-category detail.
- Allow authorised users to record activity at source, while preserving a central dataset for management reporting and analytics.
- Support filters and summaries across age group, location, service type, duration and organisational reporting level.
- Create a controlled route from requirements and data capture through to dashboards, management reports, user acceptance and training.
- Reduce commercial risk by testing the proposed solution against alternatives, challenging the initial estimate, and defining what was in and out of scope.
Results
The negotiated movement, across three scenarios
Scroll table sideways →
| Cost scenario | Pre-negotiation | Post-negotiation | Movement |
|---|---|---|---|
| Low estimate | 100.0 | 76.6 | −23.4% |
| Average estimate | 100.0 | 86.5 | −13.5% |
| High estimate | 100.0 | 83.3 | −16.7% |
Expressing the movement as indices allows the result to be reported without publishing monetary values. The supporting schedules hold a before-negotiation and an after-negotiation model, each with a minimum, maximum and average scenario.
What this percentage is
A negotiated reduction in the implementation estimate. It is not a claim that an equivalent percentage was subsequently realised as an audited cash saving.
The commercial work was not selecting a software package. The initial proposition was challenged, an alternative cost structure interrogated, the supplier estimate renegotiated, and the work bounded into identifiable implementation activities.
Commercial governance
Two controls that carry no percentage
- Variable cost exposure was fenced. Data cleaning, import and external integrations were explicitly separated from the initial contracted scope — the two line items most likely to expand without limit once a project is underway.
- The estimate was decomposed. Architecture, security and user setup, configuration, reporting, user acceptance, training and project management were itemised separately, so the price could be interrogated component by component rather than accepted as a total.
A result deliberately left out
A separate CRM licensing optimisation workstream identified savings of just under half of licence spend.
It is excluded from this headline because it belonged to a different mandate. Folding it in would have produced a more impressive number describing work this engagement did not do.
Supporting documents