In this blog post I’ll be looking back over the last 2 years. I am going to share my perspective, my ideas, and maybe some things you might disagree with.
I think it’s best to start with the context and an outline of my experience of LGR (so far).
Reflections on technology consolidation for LGR
Where I started.
I joined North Yorkshire Council in the last of the pandemic lock downs. My role was focused on preparation for vesting day, which was 15 months away.
As the Head of Delivery, I was responsible for the project management, business analysis and digital services.
As well as starting in a new organisation, in a world where we didn’t quite know what the post pandemic world would look like, the year run up to a new organisation was incredibly emotional, changeable and unpredictable, so needless to say I like working in a challenging environment.
LGR North Yorkshire vesting day!
1 April 2023
As we approached vesting day, the ‘safe and legal’ planning was moving into full throttle delivery. The new organisation’s senior leadership structure was agreed and appointed. Which included me moving up into the role of Assistant Director for Technology.
This is where I have been for the last 2 years. Responsible for the consolidation of the IT infrastructure, systems and applications. As well as the information security, cyber, support and commercial IT services for the new organisation.
The new North Yorkshire Council is big.
- We have 12,000 staff and cover a massive geographical area with ~600,000 people living in it.
- The Technology Service is staffed well, with 280 engineers, architects, product managers and analysts.
This makes a difference. It means we can do a lot of our activity in-house and have a lot of expertise on site. - On vesting day we had a total of 580 systems to look after. Which has been consolidating down every month, but is well worth knowing.
To give this blog a structure, I am grouping my thoughts into 4 groups: the organisation, the suppliers, the people, the comms, and the ‘other things’ that I think of as I am writing this.
1. The organisation
My first point of learning is that I underestimated the organisational inertia that would kick in almost immediately upon vesting day.
What we did
Pause.
I thought taking a moment for everyone to catch their breath after the manic run-up to vesting day was a good idea. But the organisation needed to keep the fire lit and the energy up.
Thousands of people landed in a new organisation with all the uncertainty that means, leading to high levels of anxiety and insecurity.
This uncertainty significantly impacted decision-making. Leading to analysis paralysis and people not wanting to make decisions because they felt they did not have the formal authority to do so.
If I knew then what I know now
Be more directive about systems consolidation.
I would push earlier with an Enterprise Architecture (EA) view and reverse the normal codesign approach.
This would allow for quicker consolidation onto a single set of systems, speeding up infrastructure consolidation.
From a consolidated position, operational services can begin incremental improvement or full-scale transformation from a stable platform with a single set of policies and processes
Mapping.
I would begin creating a regional map of the primary systems. I would create an ease and impact analysis of the options available and create a propositional design for the new organisation.
It might look something like this:
Leading to a graph that looks something like this one:
Map out primary systems and create a propositional design early on to facilitate systems consolidation.
This approach helps avoid analysis paralysis and provides clear direction.
Establish IT, data, and product owner networks to ensure collaboration and transparency.
Engaging suppliers early and providing them with detailed complexity insights is essential for effective project management.
2. The suppliers
I expected our system suppliers to be experts in their systems and capable of helping with consolidation. It was disappointing to find out that this was not the case.
What they did
Suppliers underestimated the complexity of integrations, bespoke functionalities and variations in how their systems are set up and used.
This led to significant delays and missed integrations, causing continued complexity across multiple infrastructures.
If I knew then what I know now
- Mapping
I would provide every supplier upfront with the EA map created by the network of IT networks.
Force-feed that complexity to them at every point and remind them in every way possible. - Balance
They are businesses focussed on ensuring profits and growth. We are organisations focussed on quality and safety.
Finding a balance in the project management triangle is going to be key to your successful project planning – remember you can only have 2 of the 3 components (cost, speed and quality). - Look internally
Focus on building internal capacity to undertake the work alongside suppliers. It is essential.
Create shadow product teams across the region (if this is possible, I know that sometimes this might not be inline with the multiple organisation priorities) and do not underestimate the resource requirements that continued BAU will require. That work doesn’t just stop.
This is going to mean setting really clear parameters that the IT service cannot shrink straight away. That in order to deliver the change it needs to grow and then slowly contract over the following years (note years).
3. The people
What I didn’t know two years ago was that normal portfolio management wouldn’t work.
What we did
The thing that the big firms may be selling you now? Without a simply unaffordable level of resource to manage it I am pretty sure it would fail.
So throwing £20M at a consultancy firm is just going to hurt in a whole different way.
This is because the level of IT change is so unpredictable, so unmappable and so interdependent you have to be ready to flex and adapt weekly – not quarterly or monthly. This happened!
An example of unpredictable change:
One consolidation project, in order to meet its go live date, would do so without one of the integrations.
Sounds fine right?
But missing that integration meant that a workaround had to be built in one of the old legacy on prem finance systems. And only 1 person knew how to do it.
Still, pretty normal and we can plan for that.
However, another project had its go-live date bumped by 2 weeks, requiring that 1 person to do a finance integration at exactly the same time as the integration workaround.
And the technical finance team were busy doing an annual upgrade so couldn’t help.
Then the finance system upgrade stalled.
A housing inspection landed.
And when we expanded capacity in 1 of our housing systems (note ‘1’ of them – not consolidated yet) it broke something else, and we were so busy we didn’t recertify, and a planning portal webpage went down.
All at once!
If I knew then what I know now
Consolidation is hard
I describe this as the custard layer in the middle of our normally pretty stable layer cake. It’s squidgy and unpredictable and is constantly moving.
Being prepared for when things go wrong (and they will, a lot!) is a key survival strategy.
Building this into your culture as early as possible will be beneficial.
I am not a fan of the phrase failing fast. None of us like to fail, it is genetically programmed into our amygdala to hate it. What I prefer instead is a focus on positive experimentation, positive intent, and continuous learning.
4. Communication and small things
I underestimated the need to communicate the efforts required to consolidate our infrastructure.
What we did
Some great decisions were made, including:
- a single website front end for customers.
- having a single email address for staff on day one.
- ensuring our finance system was able to function (albeit that latter one has created a significant backward step for some processes/services).
All of this created a sense of a single organisation as designed, but it did not connect deeply enough into the organisation where the niggles and everyday annoyances impacted staff every day.
We underestimated the impact cumulative small things would have on morale and on the sense of us as a single, new organisation.
I underestimated the need to communicate the efforts required to consolidate our infrastructure, so people expected on day one to be able to work from anywhere and access their (mostly on prem) systems from anywhere.
To start the communications, I described how as separate organisations we had built eight secure and well protected islands designed to keep everyone else out and fight off cyber intruders. They were also all built to different designs and needed to be reconfigured piece by piece.
If I knew then what I know now
Start sooner and get practical
I would start communications much earlier and address “small” things that impact daily work.
- Push for a single Wi-Fi setup, unified door access and a standardised desk setup across the organisation.
- Start shopping for the necessary equipment early to unify sooner and save money across the organisations.
- Do you have a mouse and keyboard on every desk?
- What is the standard monitor set up?
- Do you or don’t you allow Bluetooth?
- How do you feel about iPads?
5. Other bits and bobs
And yes, I know I said 4 parts. But these are things that are intrinsically tied into the top 4 but also worth mentioning independently.
- Migrating data is eye wateringly expensive.
I still haven’t worked out why. So plan to archive as much as you can in advance. - Set your standards for standardising asap.
It will help with all of the main points above, draw up your design principles. - Got business side IT skills? Lean into that because you want to harness every bit of knowledge as you can
- building a sharing culture early should help diminish silo thinking.
- And finally take the opportunity to cull as early as you can.
We found dozens of bits of PDF software and contracts for things that no one used anymore lurking about. This is a fun thing to do if you have an analyst brain. Or it could be something you want a contractor to do for you. But be clear you want outputs not templates else you will only get back what you already know.
You might also like to read:
Local government reorganisation: Socitm, your independent partner
Discussion: Local government reorganisation and devolution
Image from BBC News