Case studies
Examples of the kinds of project we build, grouped by the three project shapes used in the calculator. Each is marked either as a project we have delivered or as an illustration of work we could deliver in that shape. All the case studies currently on this page are illustrative examples.
The examples show the kind of scope the calculator’s effort estimates are meant to cover. Their outcomes are estimates, not measured results. We will add delivered projects to this page as they are completed.
The same terms apply to every case below. We arrange hosting, on our own servers, with a hosting partner or on the client’s own servers, whichever suits the client, and the client owns the software, so it can be moved to another host later. We support each system for as long as the client needs us, and we document it and train the client’s staff so that more of the day-to-day support can be handled in-house over time.
Simple systems
Small tools that each address one problem. Typically 1–4 engineering days.
Missed-bin reporter
The problem
A council’s missed-bin reporting runs through the contact-centre phone line. Residents wait on hold while staff retype free-text notes into the waste team’s system, and reports that need action are hard to find among duplicate and misfiled ones.
The solution
An online form, shown within the council’s existing website, where residents report a missed bin. They find their address, mark the spot on a map, choose the type of collection from a list and can add a photo. Reports go straight into the waste team’s work queue, and repeat reports for the same address and round are combined so each missed collection is dealt with once. Residents receive a confirmation email with a link to check progress, which is updated when the crew returns. The figures needed for statutory returns can be produced whenever they are needed.
What the client gets
The software itself, a full record of every change made to it, written instructions for the council’s IT team, and a half-day handover session with the member of staff named to look after it day to day. There are no recurring licence fees.
Estimated outcome
We would expect contact-centre calls about missed bins to fall by 40–60 percent within the first cycle, staff to stop typing the same report in twice for reports made through the form, and misclassified reports to fall to about a tenth of their current number. These figures would need checking against the council’s own baseline.
Single-person discount validator
The problem
Annual review of single-person council-tax discounts is run as a manual cross-check against the electoral roll. The work takes weeks and often slips behind other priorities. Cases that are missed mean lost revenue and unfair treatment between households.
The solution
A tool for the revenues team that compares the current electoral roll with the list of households receiving the single-person discount, using matching rules the team can adjust. It sorts the results into clear matches, cases that need a closer look, and claims that are probably incorrect. Each entry links straight to the record in the council’s revenues system. Because it handles personal data, it would be hosted on the council’s own servers, so no personal data leaves their network.
What the client gets
The tool, written instructions for the people who look after it, and a one-day workshop for the revenues team. The team can change the matching rules themselves, without programming.
Estimated outcome
The annual review would take days instead of weeks. Revenue recovered from corrected claims could exceed the cost of the engagement in the first cycle, depending on the size of the council’s discount roll and its current error rate.
Accessible appointment letters
The problem
A general-practice cluster wants to send appointment letters in accessible formats (large print, Easy Read, plain language), but the existing clinical-system letter templates produce only a single standard format. Staff convert letters by hand when a case is flagged, and many cases that should be flagged are not.
The solution
A small tool that takes the standard appointment letters produced by the clinical system, checks the communication needs recorded for each patient under the Accessible Information Standard, and produces a letter in the right format, ready to print. Easy Read and plain-language versions are written using a library of approved wording that the practice reviews and keeps up to date. Letters go straight to the printer.
What the client gets
The tool, the wording library (a starter set the practice can add to), and a handover session for the lead receptionist who looks after the letter templates.
Estimated outcome
The practice would meet the Accessible Information Standard for appointment letters, and patients with a recorded preference would receive letters they can read without help.
Freedom of Information request triage
The problem
An information-governance team receives Freedom of Information (FOI) requests through a generic inbox. Categorisation, allocation and deadline tracking are managed in a shared spreadsheet that has become harder to keep in sync as request volumes have grown.
The solution
A tool that collects requests from the inbox, sorts them by department using rules the team can update, assigns each one to the right officer and tracks it against the statutory deadline. Officers see only their own requests. The team manager sees all of them, with overdue requests and those at risk of missing the deadline highlighted. Acknowledgements and replies to the person making the request use standard templates, and each one is recorded.
What the client gets
The tool, set up with the team’s sorting rules, written instructions for the people who look after it, and a half-day team workshop. Performance figures for reporting to the Information Commissioner’s Office (ICO) can be produced whenever needed.
Estimated outcome
We would expect the number of late or missed requests to fall substantially, the team manager to see at-risk requests about two weeks earlier, and the double-handling caused by the spreadsheet to stop.
Platform development
Shared components used by several services or teams. Typically 12–20 engineering days.
Federated identity component
The problem
A combined authority plans to launch six online services for residents over the next eighteen months. As currently planned, each would have its own sign-in system. Without a shared sign-in, residents would need several accounts and the authority would have to look after six separate sign-in systems.
The solution
A single sign-in service that all of the authority’s online services can share. It manages residents’ accounts, keeps a record of sign-ins and account changes, and gives each service a documented way to connect to it. It works with the sign-in methods the authority already uses (the national identity service and its internal staff directory), and residents can use an email address and password instead. Residents can ask to see the record of access to their account and of what they have consented to.
What the client gets
The software itself, instructions for the teams building the other services on how to connect them, and a workshop for the authority’s group that oversees identity and access. We would expect connecting each further service to take hours of work instead of weeks.
Estimated outcome
The six planned services would share one sign-in service. Residents would use one account for all six. Records of access, and decisions about who can access what, would be kept in one place, and any later change to the sign-in method would only need to be made once.
Configurable case-management framework
The problem
Many public-sector teams that handle applications, complaints, regulatory cases or service requests have their own case-tracking system. Most of these systems have the same basic parts (stages, attachments, a communications log, an audit record, deadlines and escalation), and each is usually built separately.
The solution
A general-purpose casework system that can be set up for different kinds of case. Each type of case has its own stages, rules for moving between them, information fields and permissions by staff role. Every case has attachments, a log of communications, a full history of who did what, statutory-deadline tracking and reporting. New types of case are set up by changing settings instead of writing new software; where a service needs its own branding or particular screens, these are added on top. Each organisation has one installation, which can hold several types of case.
What the client gets
The framework, two types of case set up and in use by handover, instructions for connecting other services to it, and a workshop for the teams running those services.
Estimated outcome
We would expect later case-management needs to take hours or days of configuration instead of weeks of bespoke development. Casework would be handled consistently across the organisation, with the same form of audit record for every type of case.
Open notifications platform
The problem
Notifications to residents, such as appointment reminders, application status updates, and service-disruption alerts, are sent from half a dozen unrelated systems with inconsistent templates, varying delivery quality and no single audit record. National notification platforms exist but are not always available to local-government or community-organisation buyers, and the organisation often has limited control over how the service is run.
The solution
A notifications service that the organisation owns and controls. It sends messages by email and text message and can pass them automatically to other computer systems. It provides standard templates with each organisation’s branding, resends messages that fail, and keeps a record of every message. The organisation’s other systems connect to it in a documented way. Delivery records can be viewed for the whole organisation, for each service, or for a single message.
What the client gets
The platform, ready-made connectors for each service that will send messages through it, and written instructions for the people who will run it day to day.
Estimated outcome
The organisation’s services would share one notification platform, with consistent templates, one place to manage opt-outs, people who should not be contacted, and accessible-format preferences, and a delivery audit that can be shown to regulators.
Larger projects
Larger systems involving several organisations or groups of users. Typically 30–50 engineering days.
Streetworks coordination replacement
The problem
A highway authority’s streetworks coordination runs on an ageing product licensed from a supplier. The statutory data formats (the National Street Gazetteer and Electronic Transfer of Notifications) are well defined and the office workflow is not complex. The authority pays an annual licence fee, and changes it asks for take a long time to appear in the supplier’s product. The next renewal is two years away and the team expects a significant price increase.
The solution
A replacement system, owned by the authority, covering permit handling, noticing, publication of the register, connection to the national register, statutory returns, and a documented way for utility companies and contractors to exchange information with it electronically. It is built around the authority’s existing workflow, with the team consulted throughout the build.
What the client gets
The full system, a full record of every change made to it, written instructions for the people who look after it, and training for the member of staff named to look after it day to day. For the first six months we hold weekly drop-in sessions with the team. After that, support continues under an agreed allowance of time that the authority uses as needed. We can also help recruit a junior developer so that more of the day-to-day maintenance is done in-house.
Estimated outcome
The annual licence cost would be replaced by a one-off build cost plus support and maintenance, with more of that handled in-house over time. The system would match the team’s workflow, and changes could be made in days, without waiting for the supplier’s release schedule.
Open housing-management module
The problem
A housing association running an ageing licensed housing-management product is required by its supplier to upgrade, and must meet new regulatory requirements (Awaab’s Law, building safety, Tenant Satisfaction Measures) over the same period. The replacement the supplier offers is another licensed product, which would be just as costly to move away from.
The solution
A housing-management module, owned by the association, covering the main day-to-day work: tenancies, rent accounts, ordering repairs and dealing with contractors, statutory returns (CORE, the national record of social housing lettings and sales, and the Housing Revenue Account) and the new compliance obligations. It is designed around how the association’s housing officers work.
What the client gets
The full module, set up for the association’s estate, with tools to move the existing tenancy and rent-account records across. Handover takes longer than on smaller projects: we work alongside two named members of the association’s staff and train them to look after the system, and we help recruit one junior developer to take on day-to-day maintenance in-house. Our support continues after handover.
Estimated outcome
The association would meet the new regulatory obligations with a system it owns, and would not need to take the supplier’s upgrade. Other housing associations facing the same deadlines could use the same software.
Federated data exchange
The problem
Three health-and-care organisations (a hospital trust, a community provider and a local authority adult-care service) hold information about the same vulnerable patients. They refer to each other by phone, fax or email. Information that should be passed between them often is not, which can affect the care patients receive.
The solution
A way for the three organisations to share information about patients without pooling it, following a model used for national data sharing in Estonia. There is no central database. Each organisation keeps its own records and lets the others ask specific, permitted questions of them. The system checks who is asking, allows access only where the rules agreed between the organisations permit it for that person and purpose, and records every access. Patients can ask to see every time another organisation has looked at their record. It is built with all three organisations as joint partners.
What the client gets
A separate installation for each organisation, owned by that organisation. The three organisations oversee its day-to-day running jointly, and the arrangement is documented so that other organisations can join. The clinical safety case is completed before any real patient information passes through the system. We support the system, including its governance, for as long as the organisations need us, and help any organisation that joins to train its own staff to run it.
Estimated outcome
Information about a vulnerable patient would reach the people caring for them more reliably. Other regions facing the same data-sharing problem could use the same design, and the project would test whether this kind of data sharing, with each organisation keeping control of its own data, works in day-to-day operation across a region.