Delivering services so good, people prefer to use them
Cate McLaurin, Head of Delivery, Hackney
But we do have 6 focus areas
Head of Delivery. Cool title but what does it really mean?
I think my role boils down to this:
People not resources.
Delivering value early and often
Being clear about the problem we’re trying to solve
A team of agile delivery managers
Delivering projects, yes. But also spending time coaching others in team collaboration, delivering at pace, chunking work up so it’s manageable, visualising their work, working openly
A team of procurement and contract experts
As ICT we buy things, and we have lots of contracts
We’re focussing on getting better at this - empowering the teams to do this well. Using digital marketplace and frameworks to make it simple
Shorter contracts, more SMEs
Getting the basics right - if you don’t know what you need and why, how can you buy the right thing? And how can you work well with a supplier if you don’t manage the relationship well?
What does that mean? Can be really cheesy
For us it’s about - our apprentices, our existing staff - what skills do they need now and in the future . . ., and hiring the right people
It’s about technical skills, and it’s about people skills. Softer?
For me it’s about creating confidence. Contract management example
An innovative approach to governance
Rob/Matthew tore up everything we had - it wasn’t working
We’re using user needs, and agile manifesto to guide us
Why is it innovative? Because it truly starts with - trust the team
Work in the open by default — because that enables us to reduce formal governance
Most decisions should be made at team level — that’s where the best information is
When a decision impacts more than one team — teams are responsible for discussing and agreeing what to do between them
Where a decision impacts us all — we need to discuss that more formally at a senior level
Clear protocols and guidance help us so we avoid overwriting each other’s decisions.
working openly to promote
sharing and common re-use
UR library, API platform, public weeknotes, HackIT blog
working with services to redesign end to end service
It’s not just digital
It’s not just agile
Service assessments, GDS tech code of practice, HAL checklist
Conclusion: We had a big team, with no common purpose and resource-hungry attitude, so we started with ‘Why’ (the manifesto). We learnt ‘how’ by not having a strategy but acting entrepreneurial to show what was possible whilst learning how we did that. We’re now working hard to connect every day work to our approach by: Embedding user needs in everything we do. governance as a service principles, communicating the ‘why’ before the ‘what’ and the ‘how’, Experimenting with short-term, high intensity areas of focus
Local digital service standard
Teams to tell their story, annd get feedback. We expect high standards. And empowered teams.
They’re not a gateway. But they are a challenge. And they provide assurance.
Trust the team.
A mix of met and partially met. Peer review - and open challenge on use of agile. Team decided how to tell their story. Assessors gave recommendations and the team went away to ‘fix’ the things they needed to fix. 6 - is data secure, team hadn’t had the review from our security team through yet. Also Partially met until readme format agreed and then delivered.
What have we learned? Left to tell their story in a supportive environment teams are often quite hard on themselves! Feedback so far is that whilst it’s hard (and a bit scary) preparing for an assessment, it’s helpful to the team. Gateway - surprise form some that we don’t go back and check what the teams done as a result.