Your team must have a clear plan to measure success after the work goes live. This means setting up simple tools to collect performance data, such as website analytics, drop-off rates, and resident feedback.
However, just collecting data is not enough. You need an agreed routine to review this information regularly. Most importantly, your team must have the time, budget, and resources set aside to actually make continuous improvements and fix problems based on what that real-world data tells you.
What this looks like
- Plan for ongoing work, understanding that launching the service to the public is just the first step, not the finish line.
- Put simple tools in place to measure real-world performance, such as website analytics, drop-off rates, and direct resident feedback.
- Set up a routine for the project team to sit down and look at the data together to spot trends.
- Use the data to actively identify exactly where residents are getting stuck, making mistakes, or dropping out of the process.
- Keep budget, time, and staff set aside after launch so you can actually build the improvements and fix the issues you uncover.
The questions
- Do you have tools in place to measure live performance and gather direct feedback from residents?
- Does the team regularly meet to review this data and identify exactly where users are struggling or dropping out?
- Have you kept the dedicated time, staff, and budget needed to actually fix problems and improve the service after launch?
How this links back to the Government Service Standard
This checklist point broadly maps across to:
- 7. Use agile ways of working
- 8. Iterate and improve frequently
- 10. Define what success looks like and publish performance data
Full guidance notes
In local government, there is often a huge buildup to the launch day of a new service or digital tool. A dedicated team works tirelessly for months, the software goes live, a celebratory email is sent to stakeholders, and the project team is immediately disbanded and reassigned to the next crisis.
This is the traditional ‘project’ mindset, and it is a recipe for broken public services.
Why? Because no matter how much research you do beforehand, a service will only face its true test when the real public starts using it. Needs change, policies shift, and unexpected behaviours emerge. If there are no mechanisms in place to review performance and make improvements, the service will immediately begin to degrade.
This guide explains how to shift from a ‘fire and forget’ approach to a culture of continuous improvement, ensuring your services actually get better over time.
1. Treat the Launch as the Start, Not the Finish Line
The most significant barrier to improving public services is the misconception that ‘live’ means ‘finished’. When a council builds a physical park, they know they must employ groundskeepers to mow the grass and fix the swings for decades to come. Digital services require exactly the same ongoing maintenance and care.
1.1 Shifting the Mindset
You must move your council away from viewing service delivery as a one-off project with a fixed end date. It is an ongoing commitment to the residents. The launch of a new online form or internal system is simply the moment you begin gathering the most accurate data possible about how well your solution actually works.
1.2 In Practice:
- Manage expectations: Clearly communicate to senior leaders and committee members that the launch is only version 1.0, and it is expected to change.
- Keep the team intact: Avoid immediately dismantling the multidisciplinary project team the day after the service goes live.
- Plan for iteration: Build a roadmap that explicitly schedules time for post-launch adjustments.
2. Track the Right Data
You cannot improve a service if you do not know how it is performing. However, this does not mean you need to implement incredibly complex, expensive data dashboards that no one understands. You simply need reliable ways to see what residents are doing and hear what they are saying.
2.1 Listening to the Evidence
Good performance review relies on a healthy mix of quantitative data (the numbers that tell you what is happening) and qualitative data (the feedback that tells you why it is happening).
2.2 In Practice:
- Web analytics: Use simple, privacy-compliant tracking to see how many people start a process versus how many actually finish it (the drop-off rate).
- Call centre logs: If a new digital parking permit system goes live, but the contact centre suddenly receives an extra 50 calls a day about parking permits, your digital service has failed.
- Direct user feedback: Add a simple, optional feedback question at the end of a transaction, such as, “How easy was it to use this service today?”
3. Hold Regular Reviews
Collecting performance data is entirely useless if nobody looks at it. Data sitting in a spreadsheet does not improve a public service; people having conversations about that data do.
3.1 Creating a Routine
Your project team must establish a strict, protected routine to sit down and review the information you are gathering. This should not be an annual audit, but a frequent operational habit.
3.2 In Practice:
- Schedule performance meetings: Set up a monthly or fortnightly review session where the multidisciplinary team (including developers, designers, and frontline staff) looks at the data together.
- Avoid blame culture: If the data shows that 40% of residents are failing to upload their evidence documents correctly, this is not the residents’ fault, nor is it the fault of the developer who built the upload button. It is simply a shared problem for the team to solve.
- Share findings openly: Publish high-level performance data internally so the wider council can see how the service is performing and learn from your journey.
4. Find the Pain Points
When you review your performance data, your primary goal is to act like a detective. You are looking for the exact friction points where the process is failing the public.
4.1 Targeting Your Effort
You cannot fix everything at once, so you must use the evidence to prioritise. By pinpointing the specific steps where residents struggle, you can direct your resources to the changes that will have the biggest positive impact.
4.2 In Practice:
- Look for bottlenecks: If it takes an average of fifteen minutes to get past step two of a housing application, but only one minute for all other steps, step two needs an urgent redesign.
- Analyse the drop-outs: Find out exactly where people are abandoning the process. Are they leaving when asked for a specific piece of information they might not have to hand?
- Listen to the frontline: Frontline customer service staff will usually be the first to know where the pain points are, as they are the ones fielding the confused phone calls. Make sure they have a voice in these review sessions.
5. Fund Continuous Improvement
This is the most critical point, and the one where local government projects fail most often. Identifying a pain point is pointless if you do not have the money, time, or staff to actually fix it.
5.1 Budgeting for the Future
Traditional funding models often allocate 100% of a project’s budget to getting it launched. Once it is live, the budget is gone. You must actively fight this model to ensure your service does not stagnate.
5.2 In Practice:
- Retain a post-launch budget: When initially requesting funding, always ring-fence a percentage of the budget specifically for continuous improvement and fixing post-launch bugs.
- Keep developer capacity: Ensure you still have access to developers and designers after the launch date. A service cannot be improved if there is nobody available to write the code or rewrite the content.
- Empower the team to act: When the team identifies a quick, necessary fix through their data review, they should have the authority to implement it rapidly, without needing to draft a completely new business case for a minor improvement.