Image with a black background and a person holding a tablet. Includes the letters CRM in blue and 5 icons that represents the elements of a CRM.
Over time, we will add a suite of end-to-end services that make it easier for residents and businesses to transact with us online, a key enabler of the Luton 2040 vision.
I’ve been in post for just over a month. I’m predominantly a developer, but one of the things I’ve learned is that you don’t need the platform to be ‘live’ to start creating value. Right now, we’re focusing on the groundwork so that when the platform is spun up, we can move fast with confidence.
Sprint 0: the work that makes delivery smoother later
You’ll sometimes hear this phase described as “Sprint 0”. It’s the set-up sprint: less about building resident-facing features, and more about putting the foundations in place so delivery is smoother later.
I’ve been spending time with James Bovington reflecting on what we’ve learned over the last 10 years of developing low-code platforms.
The goal is simple. Repeat what worked and avoid the pitfalls that make platforms hard to use, hard to support and hard to scale.
Ten steps of preparation
Waiting for implementation can feel like being stuck on the starting line, but it’s actually a great opportunity to remove uncertainty. In practice, that means turning ‘we should’ into clear, testable decisions. Reflecting on the last month’s work is useful, and this time it feels far more structured than my last implementation, in the early days of COVID:
1. Application architecture
Agreeing the overall shape of what we’re building, positioning Luton CRM as the hub, with apps and services built around it. We’re clustering work around shared capabilities (for example: corporate functions, reporting issues around the district, and booking services) and aligning delivery to corporate strategies, so we avoid creating disconnected point solutions.
2. Connected journeys
Mapping how the pieces join up so residents get a seamless experience online and staff have the full case context in one place, rather than chasing information across multiple systems.
3. Core data model
Defining the key entities we’ll use everywhere (person, business, place and case) and the relationships between them, so data is consistent and reporting is meaningful.
4. CRM design thinking
Outlining what Luton CRM needs to do (case types, queues, ownership, SLAs, communications, automations, reporting and so on…) so we can configure consistently.
5. Data and integration readiness
Identifying the systems we’ll need to connect to, the key data entities, and the data-quality issues that could trip us up.
6. Security and governance
Aligning on environments, access controls, logging/audit needs, and what needs to go through assurance.
7. Build standards (the start of our playbook)
Creating shared guidance so we build consistently across low-code, Drupal and integrations. This covers architecture patterns, naming and configuration conventions, accessibility and content standards, testing expectations, and how we release and support changes so teams can move quickly without avoidable risk or rework.
8. Ways of working and backlog shaping
Agreeing how we’ll run sprints, capture requirements, manage a backlog, and get feedback from service teams, then breaking down projects and epics into small, deliverable slices with acceptance criteria and clear dependencies.
9. Defining reusable patterns
Agreeing how we’ll handle common needs (identity and authentication, notifications, document capture, payments, and case updates) so we don’t reinvent the wheel per service.
10. Getting ready for delivery
Setting up ways to test, release, and support our applications and the teams who use them.
We’re also taking inspiration from colleagues in other councils. One example is the activity stream built by Adur & Worthing, pulling together all interactions within a case into a single, easy-to-digest view. Patterns like that help us design Luton CRM around how staff actually work day-to-day.
None of this work is as visible as a new online form or a shiny dashboard, but it’s what helps us:
- deliver the right things
- avoid costly rework once the platform is in place
Getting this right early helps us move quicker later, because teams deliver better when they share a backlog, agree standards, and have effective ways to communicate.
The team
A big part of Sprint 0 is designing the team that will build and run these services. We’re exploring whether we can shape a single development team that supports both low-code and the website (@LocalGov Drupal), alongside all the other disciplines we need to be truly multidisciplinary.
- Product ownership: setting outcomes, making priority calls, and keeping us focused on value.
- Business analysis: turning service needs into clear requirements, rules and acceptance criteria.
- User research: grounding decisions in real resident and business needs (including assisted-digital considerations).
- Content design: making sure content is written in plain English and online transactions are easy to complete first time.
- UX design: designing flows that work end-to-end, not just screen-by-screen.
- Development and testing: building, integrating, and assuring quality with a shared approach to standards and support.
- Delivery: removing blockers to ensure projects get over the line, on time and in budget.
Team structure diagrams have been drafted and re-drafted, and DDaT job descriptions pulled together for all the roles we will need.
On the people side, some colleagues in the team have already started their basic training on the platform. I’ve also been meeting with teams across the organisation to talk through what the platform could enable and to capture their ideas, so our early delivery is shaped by real service needs, not assumptions.
The pipeline
In parallel, we’re building a pipeline of work that already stretches out to 2028. That isn’t a fixed promise of delivery dates (although we have a fair few hard deadlines along the way), it’s a transparent view of demand, dependencies and sequencing.
This means we can:
- prioritise well
- plan capacity realistically
- keep the focus on the journeys that will make the biggest difference.
What happens next
As the Liberty Create implementation lands, we’ll start configuring the foundations of Luton CRM and delivering our first end-to-end journeys. The aim is clear:
- reduce avoidable contact
- speed up resolution
- give residents and businesses the best digital experience so they can get things done in the way they expect
If you’re a colleague and you have a process you think should be prioritised, or a pain point that keeps coming up, please get in touch. The best time to shape the way we build is right now, while we’re still laying the rails.
Like
Love
Haha
