Digital transformation in the public sector creates a real opportunity to improve services, modernise infrastructure and make life easier for the people delivering those services every day.
Over the last five years, the Back Office Planning System (BOPS) project team, supported by the Open Digital Planning community, set out to build a modern back-office planning system for local authorities. Along the way, we learned a huge amount about what it takes to deliver complex software in a mature and highly constrained public sector environment.
Many of these lessons came from things that didn't go exactly as expected. That's not a bad thing. In fact, some of the most valuable insights came from the challenges we encountered. Rather than seeing them as obstacles, we see them as lessons that can help future teams deliver similar transformation programmes.
If there's one thread that runs through all of them, it's that the hardest parts of BOPS were rarely about the technology itself.
The reflections below come from a series of open and honest retrospectives involving designers, developers, and planners who were involved throughout the programme.
Success is bigger than adoption numbers.
Not every win shows up in a deployment count. One of the most genuinely positive outcomes of BOPS was its effect on the wider planning technology market, raising expectations, putting pressure on incumbent suppliers, and helping councils become sharper, more demanding customers who ask better questions about data standards and interoperability than they used to.
Sector change often moves slowly and sideways rather than head-on. Sometimes the biggest contribution a programme makes isn't the thing it shipped. It's the bar it raised for everyone building in the same space afterwards.
Long-term agile delivery requires discipline.
Delivering a product over multiple years is very different from delivering a short-term project.
Teams are constantly balancing pragmatism and craftsmanship: building enough to learn quickly while still maintaining a sustainable product. Being open about that tension helps teams make better decisions and creates shared understanding about why certain trade-offs are being made.
Over time, technical debt accumulates and early decisions become harder to reverse. Maintaining architectural discipline, investing in refactoring and regularly reviewing technical direction becomes increasingly important as a product develops.
The same is true from a design perspective. Products that evolve over several years and involve multiple designers can gradually lose consistency. At Unboxed, we’ve seen that regular design reviews and audits every ‘X’ months, help maintain a coherent user experience and prevent unnecessary complexity from creeping in.
Invest in continuity and onboarding. People matter.
One of the strongest assets throughout the BOPS programme was the continuity of both the team and the local authority partners involved. Long-term relationships created trust, strengthened collaboration and allowed knowledge to build over time.
At the same time, change is inevitable. New people join projects and others move on.
For new team members, planning is a complex domain with its own legislation, terminology and history. Without proper support, it can take a long time to become effective. One team member reflected that an initial handover meeting, however well-intentioned, only got them so far; it was time spent working alongside the existing team that really helped things click.
Structured onboarding, including product history, domain knowledge, architecture overviews and opportunities to shadow existing team members, helps new joiners become productive much more quickly. It's a small investment that pays off many times over on a multi-year programme.
Treat routes to market as seriously as product delivery.
Perhaps the most important lesson from BOPS is that building the product is only part of the challenge.
The barriers to adoption were often organisational and operational rather than technical. The bigger and more capable a product becomes, the harder it can be for any single organisation to feel ready to adopt it. There’s simply more for them to get comfortable with. With hindsight, the team felt that identifying something smaller but genuinely deployable earlier on, even something as focused as a self-contained pre-application advice tool, could have helped build a base of live users while the rest of the system was still taking shape.
Stakeholder relationships also shape a programme more than people often expect. In the earlier stages of the project, a funding partner understandably wanted visible progress to show at the end of each sprint. At times, this meant the team focused on demonstrating progress over the slower work of getting things right. The relationships that worked best in later years tended to be with councils that genuinely wanted to change how they worked. Taking the time to understand what they valued about their existing systems, as well as what frustrated them, made a real difference.
A small group of engaged, vocal stakeholders is a real asset, but it helps to have a wide enough group that no single perspective shapes the product more than it should. Every local authority has slightly different processes, and feedback from one council can feel like a strong signal in the moment. The challenge is to identify common patterns, distinguish local preferences from wider user needs, and protect a minimum viable scope that delivers value across different councils.
Having someone able to hold a steady view of “this is what we’re building and why” gives the team stable footing when feedback pulls in different directions.
We always try to appoint a Product Owner from a client team. In this case, that was a planning officer who brought the voice of the user into every conversation. We’ve also documented several patterns developed through this work and shared them at bops.org.
Future programmes should think about route to market much earlier. Introducing a single service or module before replacing an entire system can help organisations build confidence at their own pace.
What this experience has taught us.
Looking back, one of the clearest lessons from BOPS is that the hardest challenges were rarely technical.
Building good software is important, but successful transformation also depends on adoption, organisational change, stakeholder engagement and market readiness. Future teams should think about these factors from day one, alongside the build, rather than treating them as something to address once the product is finished.
The experience of BOPS shows that it's possible to build high-quality digital services in complex public sector environments. It also shows that delivering the technology is only part of the journey. Real transformation happens when product strategy, delivery, adoption and implementation move forward together.
