Further up, Farther In

Do you ever have a day when despite the mayhem going on all around you feel energised and happy that you’re right where you should be?

I had one of them last Friday, and my recognition that I was having one came through a brief 30 min meeting in the middle of the day, sharing some information about the capabilities we’ve got available to improve the use of social media in engaging with people. It turned into a chat about all the things we are doing, and how the opportunities to do our best for people in Bristol had increased over the past few years. I found myself talking about the things that fire me up and keep me working in Bristol (and local government generally) rather than running off to the private sector for a higher paid but (in my eyes) less meaningful job.

That conversation was bookended by two long meetings about major projects, delivering some really big changes to our services. We made real progress in both, and neither were ‘talking shops’ – they were real exchanges of expertise, where personal contact and looking people in the eyes as we discussed was important to sense understanding, reactions to proposals, and commitment to action. My job can often be wall to wall meetings, and certainly all the ones that are death by status update need to be killed, but ultimately the role of Chief Enterprise Architect is to engage, shape, lead and facilitate the organisations approach to designing the future – all things that need a strong human connection.

I also got a major kick from seeing some massively exciting new products and services that are available to the local government market now. For too long our frontline staff’s willingness to innovate and desire to focus on what really matters for service users has been seriously blocked or diluted by poor systems and technology. But real alternatives are out there now, and I’m sure we will see them in action at more and more councils.

As GDS puts it, it’s time for “technology at least as good as people have at home”…

My day ended catching up with an old colleague who helped us create EA in Bristol. As we talked through all that had happened since 2009, and I showed off our new workplace in 100 Temple Street, it came home to me how much we have delivered, and how far our in-house teams have come over that time. We’ve had lots of help and expertise from suppliers, contract staff and colleagues across the public sector, but our core is a team of permanent Bristol City Council people who have grown together and supported each other to learn fast and deliver what the city and council needs.

Onwards and upwards!

Building and running an agile delivery organisation – Doing Digital in Bristol pt. 2

It’s taken me a long time to get this post into shape and published. We’ve been living this journey for the past year and have a pretty clear understanding of where we’ve been, what we’ve done along the way and where we are going next. But articulating that clearly for an outside audience is tricky – I don’t want to present a glossy picture to you, that’s not helpful. If I was reading this, I think I’d want to hear what’s gone well and what mistakes we made so that you have a chance to learn and do things differently.

Although I’m responsible for the words used to tell this story, the actual work I’m describing was very much a team effort. My colleague Tara runs the Programme Management Office, and she and I have jointly led this transition to a new approach. It’s her team who are the heart and soul of the service redesign projects. Much of what I’ve written here is based on the learning and developing practices that have emerged in our joint design and delivery teams.

Where we’ve been…
Like all councils, we’ve got years of experience running traditional projects, based around PRINCE2 and a waterfall style solution development lifecycle. We felt that we were fairly good at delivering these projects, and had introduced a number of professional disciplines alongside Project Management – Business Analysis, Enterprise and Solution Architecture.

But the truth is that far too many of our projects took a very long time to come to completion. In fact too many of them took a long time to progress through an initial feasibility and design stage before turning out to be unable to make a business case – we weren’t quick enough at identifying and delivering value for the organisation, or for the public.

Our process involved several sequential stages, with people operating in professional silos, and throwing outputs over the fence to the next silo. We made a few changes along the way to improve collaboration and flow of work, reducing handoffs, but it was all tinkering around the edges. As a result of the combined financial challenge and rising demand for modernised services we ended up with a complex portfolio of 14 programmes, each with many projects, all operating to their own objectives and often cutting across each other, or distracting attention from important common themes.

Over the past few years it’s become increasingly obvious that this approach can’t deliver the results we need – whether it’s because we aren’t close enough to user needs, or because we take too long to deliver working solutions that have value to the organisation, or that the solutions themselves are too heavyweight and based on legacy views of what local government is about

We began to investigate ways of breaking out of the traditional approach in 2013. We had defined a new council wide programme of work focused on customers and process improvement, and within this had recognised that our ambitions to deliver a major shift to online channels meant that we needed to invest in new infrastructure and a new way of delivering services. This is when we began to look seriously at the emerging agile digital methods that GDS were promoting and decided to commit to them for our new online services.

And then came a decisive break with our past, when Nicola Yates joined us as City Director a year ago and led us in radically revising our approach to change, creating a single whole council programme, bringing every aspect of what needs to be improved or transformed in this organisation into one governance and delivery structure.

This gave us a number of major opportunities. We brought all of the work on delivering digital services and the associated process and technology change into one place, with my leadership for architecture and design and Tara’s for delivery. We had an injection of radical thinking courtesy of Tom Steinberg, who came to our board and challenged us to be bold and drive through a user needs focused vision in the spirit of GDS – and we got the explicit support of our City Director to do this.

Nicola also re shaped our approach to justifying investment and agreeing common approaches. Her view was that there would be only one way of doing things in Bristol and that the business case for the whole programme was the key, not individual projects – although of course each and every project has to contribute towards the transformation of the council and the savings we need to make. But taking a view across the whole programme, and recognising that some costs supported benefits in multiple projects meant we could build the infrastructure we needed to deliver digital services.

Delivering our digital services infrastructure
At the same time that we began to drive towards truly digital services, and to build the new infrastructure, we had to create a new delivery team structure to do this, and needed new skills and capabilities. We didn’t have an inhouse development team, so we used G-Cloud to source a digital agency who were to bring agile development and UX skills to the task. We put a project manager in place who had some experience of agile and began to build up roles like product owner.

It wasn’t long before we hit the first of our challenges – we found product ownership and management difficult. Our ability to write good user stories wasn’t good enough, and our suppliers weren’t really strong enough in agile methods or confident enough to be honest about that with us. We found ourselves coming out of sprints with very little done and more stories written than done – almost a negative velocity!

Around this time we recognised the need for an agile coach but didn’t make the move to bring them on board for some months – just because we were too bogged down in the day to day – but in fact once we made the effort to find an appropriate coach it made all the difference – that and the fact we were lucky enough to find Sarah Prag, ex GOV.UK product manager!

So alongside product management, the other key activities and skills we needed in this phase of our evolution included:
a. Solution and technical architecture
b. Commercial management of suppliers within the agile process
c. Testing

As we built our infrastructure and began to design and deliver digital services on it in two week sprints we found a new challenge. Transactional digital services aren’t like building a web site to provide information advice and guidance. They need careful integration and testing before rolling out to the public. Although adopting user stories and agile scrum based techniques can help in some ways they also introduce more issues.

You need to blend user story driven front end development with the often complicated design and build of integrations, procurement of new services or upgrades to line of business systems. When the refinement of user stories during sprint planning uncovers new issues or an improved understanding of what back end infrastructure is needed, you have to redirect staff and suppliers who may be more used to delivering to a fixed scope of work. You need the right contractual basis and the right culture, attitudes and behaviours in your team for this to work well.

You also need to develop the operating procedures with your IT service – whether internal or outsourced. Agile development and delivery won’t work if it bumps up against traditional multi-week change control processes. You need to be able to support multiple environments, continuous build and integration, and an agile testing cycle. Clearly there is still rigorous control over transition to live, but if you want to run public betas they won’t be of the same nature as a traditional live service.

We had lots of adventures in this stage of our journey – wrong turns, confused wandering in the fog, arguments about what was the right direction to head in. It took strong leadership to get the team focused and facing in one direction – both at the strategic level but also from the delivery team manager role.

Part of the problem – with hindsight – is that we moved to an agile approach whilst still building the infrastructure, which would have been better as a standard waterfall project. Once we had the services and technologies in place we could have dived into agile delivery of services with fewer complications.

As I noted earlier, we also didn’t get an agile coach in early enough. Once Sarah was working with us she helped us to focus on the root cause of the challenges we were experiencing. We did this through standard sprint retrospectives. The fundamental issue we identified was that we had moved to delivery too quickly, without a deep and comprehensive enough discovery phase. So we worked with Sarah to define a detailed guide to discovery and she coached the next couple of projects through that stage.

Evolving into Service Design
So the next stage of our journey has been travelled over the past 6 months. The infrastructure is pretty much in place, so our projects are focused on user needs driven, outside-in, service design, enabled by these new digital opportunities. Again we needed to evolve our skills and capabilities, and the shape of the teams that deliver redesigned services

Working with Sarah Prag we’ve really unpacked what Discovery means, identifying three sub-stages – learning, shaping and planning. Within these stages you gather a number of inputs, do a number of things to them, and produce some outputs.

(Sarah has asked me to point out that this visualisation of the design process has been stolen from the Design Council’s famous “double diamond” – her cheeky addition of the ongoing “run and improve” phase is the key difference)

SP-discovery-delivery diamonds

If you look at it with your eyes half closed, the list of activities looks very similar to a typical PRINCE2 project in startup and initiation stages. But there are crucial differences.

For a start there’s the intensive focus on customer experience, rather than internal process. We are absolutely starting from user needs. Of course we do then blend in an understanding of the business function and organisation – this is all framed within the need to reduce our annual operating costs by £85m over the next couple of years so clearly we have to know where the waste and failure is in our operational procedures. But the important thing to take away is that you first work through how the service could be reimagined to meet user needs through digitally enabled means, and then turn to the process. We’ve found that entire chunks of current activity are simply swept away – they only exist because we created a complex set of rules around the limitations of our capabilities and policies created in a pre-Internet world.

Another important difference is that you co-locate a small team of people in one space, and support them to think visually and collaboratively, not write reams of documentation. We’ve loosened the expectations of documentation and allowed our teams to discover what is absolutely needed, and are now explicitly redefining what makes up the standard set of products.

The main roles in these redesign teams are the Project Manager, Business Analyst, CX expert, Solution Architect – and of course the subject matter expert from the service.

And that brings us up to date. We are about to embark on the next stage of evolution in this story. We want to draw service managers into this way of delivering continuous agile digital service redesign. It’s very early days, but we expect to blend the specialist teams we’ve created to date with operational staff and managers to increase capacity and enable a true continuous improvement approach.

We are working on an approach to scaling agile delivery now and will share more when we can.

Digital Services Infrastructure – Doing Digital in Bristol pt. 1

About two years ago we began to think through the architecture for a better digital services to our citizens, focusing initially on meeting “universal” needs – things that pretty much every resident or business in Bristol might have, that could be accessed and as far as possible delivered using digital technology.

We sketched out a blueprint for these digital services to customers, focusing on the capabilities that would be required, and then unpacking them into the business and application functions that would make these capabilities real. This phase of our work was unashamedly non-agile – but for those of you shaking your heads about our failure to commit to emergent architecture based on user needs, just because “Big Requirements Up Front” and “Big Design Up Front” are bad ideas doesn’t meant that a big picture enterprise architecture vision has no value. We aren’t in the position of a lean digital startup, with a blank sheet and free rein to innovate. All large organisations with history have an existing architecture and the infrastructure that embodies it, and this needs to be taken into account and used wherever possible. (Take a look at Scott Ambler’s posts about the architecture aspects of Disciplined Agile Delivery for more on this.)

In addition, we have a number of strategic goals as a council, quite separately from the individual user needs that might be discovered when we look at a single service. These include building an open standards based citizen account that can interoperate with the Verify scheme built by GDS, and enable citizens to use Personal Data Stores if they wish to; a platform that can support a unified experience across multiple services, some developed from the ground up by the council and digital agencies, some bought as pre-built services from third party providers; the ability to define, create and manage integrations with systems we run ourselves and services that other parts of government and third parties provide.

So in late 2013 we had a reasonably clear idea of the capabilities we ended and the technologies that would contribute to them. We called this collection of technologies our “digital platform” – the structure that we could build on to deliver services. It was composed of a number of elements, mostly implemented using products we had selected and procured in the previous few years:

  • A portal framework, providing consistent UX, responsive design, APIs and a structure for managing multiple transactional services – Liferay Portal
  • Identity Management – ForgeRock’s OpenAM

The digital platform interoperated with a number of products that provide core infrastructure services to the council:

  • Integration with backoffice systems – Tibco’s ActiveMatrix ESB products
  • Business Rules & Process Management – Tibco’s ActiveMatrix BPM suite
  • Document services – Alfresco One
  • Customer record – Salesforce.com

Digital Platform High Level Architecture

So this gave us a toolkit to use, as appropriate, to construct digital services that meet user needs. Since April 2014 we’ve been working with these tools, and learning to work in an agile/iterative way – a story I will tell in my next post.

3 commitments

Yesterday, at the Liferay Portal Solutions Forum in London I had the latest in a series of brilliant networking and knowledge sharing experiences that stretch back over the past couple of years. As I’ve always found when people from 3 or 4 councils have an opportunity to get together outside their normal working routine, we share a passion for doing things better and want to learn from each other.

I heard from and had conversations with folks from Poole, South Worcestershire’s shared ICT service, Camden, North Yorkshire and others. In every case there was something that we in Bristol need to learn from them, or that we could contribute to help accelerate their journey. I made the links to @localgovdigital in our conversations and suggested people get their projects onto Pipeline to help us all start to see the opportunities for real practical collaboration.

But at the end of the day after a long conversation with Francois Mounier from Camden, Sarah Jennings from Knowledge Hub and Elinor Ni Chathain from Bristol, we reflected that so often the passion for collaboration is swept away in the intensity of our day jobs, especially nowadays with so many fewer people in our teams and so many things to do. So we made some commitments to each other that we would act. Here are mine:

1) by Christmas, put all of our live and planned projects onto Pipeline
2) write and publish the three blog posts I promised to do back in August about Bristol’s approach to doing digital
3) share the materials we have developed to support the Discovery phase of digital service redesign projects on Knowledge Hub

So there you are – public commitments are usually more likely to be kept 🙂 You can check up on my progress over the next few weeks!

“Doing Digital” in Bristol City Council – updated

Almost a year ago we began to plan a major new approach to transforming services to our citizens, businesses and visitors to Bristol.

During this time we’ve done three main things:

  1. Designed and built the infrastructure needed to provide end-to-end digital services
  2. Created a new organisation structure to deliver digital services in an agile, user needs led way, and iterated it as we learned what worked and what didn’t
  3. Used agile methods and focused on user needs to help us redesign our first two services digitally, with several more in the pipeline

Through this time I’ve been fortunate to work with a number of great people inside the council, and have been learning from colleagues across the country in the LocalGovDigital network. I’ve talked about the work we’re doing on several occasions but we’ve never gone into much detail.

So I have a lot stored up to share, and figure it’s best to split into several posts – at least one on each of the three areas above. When I originally wrote this post in late June I had high hopes that I’d write and post them in July, but reckoned without the pressures of work as I headed towards a long holiday!

We are now within a few days of launching our first digital service built on the new infrastructure using the new methods and team structures, so we can show as well as tell 🙂 Over the next couple of weeks I will take some time to share what we’ve done and how we’ve done it.

 

Defining Digital… another contribution

Matt Jukes () wrote a great blog post on the meaning of ‘digital’ which led to a bit of conversation on Twitter this morning between Phil Rumens (), Matt and me – but 140 characters isn’t enough space to share the definition of Digital that we’ve used inside Bristol City Council, so I thought I’d better blog about it instead.

As we began to build our local digital approach in the council we explained what digital meant thus:

“Digital means services that are designed from the ground up to be discovered, requested, processed and delivered using technologies enabled by the Internet, by mobile devices, by wireless networks, within a context of consumer use of these technologies and social networks. Digital implies end-to-end, not just an electronic front-end and a manual back-office. Digital implies a relentless focus on user needs, over service silos organised around the traditional hierarchies of government structures.”

So there you go, not necessarily the shortest or only definition you might need, but it’s helped us to be clear about the various dimensions involved in a digital approach to service transformation and why it’s genuinely different from things we’ve done before as a council and as a sector.

What impact would a Local GDS have on the market?

I’ve read some really great posts on all angles of the Local GDS idea in recent weeks from a lot of people I respect.

Ben Welby made a number of cogent arguments in favour.

Phil Rumens suggested why he thought it shouldn’t happen.

Eddie Copeland of Policy Exchange has argued strongly for it to happen – and I find much of merit in his riff about open standards being a critical enabler of change.

Sarah Prag added a particularly interesting flavour to the discussion, really focusing on exploring aspects of the problem rather than jumping to the solution

Rob Miller expresses many opinions I share in his post pointing to the potential stifling of smaller local providers if we take a monolithic approach.

And many people track the whole discussion back to a post by Rich Copley – itself inspired by Dominic Campbell’s tweet in December 2013.

(Anyone I’ve missed out – sorry!)

Some of these posts explicitly mention the way that a number of local government system suppliers are making a nice income from selling the same products to 300+ local authorities in England, and ponder on how much money could be saved by renegotiating large volume contracts with a single Local GDS, removing lots of software support and infrastructure duplication at the same time. They also talk about having one CMS and one set of integration and related back end services.

For many of us who work in local government, in IT or more latterly digital teams, it’s easy to pile up stories of the difficulties we’ve had trying to work with certain suppliers, and the tired legacy systems they provide – many of which were written in the 1980s and have never been overhauled. Boston Consulting Group would be pointing out “cash cows” all over the place in the council applications landscape! Whilst I could try for a bit of fairness, there are indeed many instances of products that simply aren’t fit for purpose for the world of digital services and user needs driven service design.

But, and it’s a big but, the market is changing. There are lots of new entrants, many of them SMEs, many working with a wide variety of open source and open standards based products and services. But they aren’t all using the same products – there are multiple CMS, portal, integration, EDRM, and related systems, running on several different infrastructure stacks.

So even if we think that the local government line of business apps market deserves to be shaken up and the companies in it should lose business, revenue and some should probably go out of business (just a thought experiment here people, stay with me…) do we really think the same about all these keen new entrants? When we decide on the one CMS product for the Local GDS to use, and the single integration platform, and the chosen EDRM, are we all clear and happy that every supplier who doesn’t support those products is barred from competing for the work that Local GDS has to offer – and will have to weather the financial consequences.

What about the fact that depending on the products that get chosen, some parts of the country will be winners and some losers – for instance there happen to be lots of PHP coding companies in Bristol, so adopting Drupal as the platform for Local GDS would be great for them. But all the Umbraco developers in a.n.other council’s geographical area would lose out unless they switched platform.

Of course if we ensure that the products support major open standards, and if they are also open source, then lots of companies can provide services to Local GDS, but that doesn’t minimise the initial impact on many companies that are not trying to exploit councils, simply providing an honest service for the needs we present.

How would all this stack up in terms of open competition and trade law? Does anyone know? I certainly don’t, but I suspect one or two businesses would be consulting legal experts and mounting sustained campaigns to pull the rug out from under Local GDS and its supporters. Just look at what happened to Massachusetts back in 2006 when it tried to adopt a fully open standards approach to their enterprise IT architecture, or indeed what happened to GDS and the Cabinet Office in the recent history of open standards adoption in the UK.

So I think there are many commercial difficulties with our ability to implement a Local GDS that had a major infrastructure element to it’s role. That’s not saying it shouldn’t happen – I’m still not decided which side of the fence to jump off myself 🙂

The other angle to this of course is that every council that has invested in this variety of systems and suppliers has a large amount of sunk cost in their current technologies – which of us is ready to simply write that off and walk away? Most councils would want to ensure there was an appropriate return on investment in their assets and therefore would want to look at a phased migration to any new centralised platform.

And another thing – Phil Rumens has argued passionately about the local democratic aspect of councils as a barrier to adopting a Local GDS. It’s not just about ward members representing localities – Chief Execs and Mayors/Leaders have great ambition for their areas, and often want to ensure that economic success and the distinctive local character of an area are sustained by the way we spend our technology budgets. I suspect that no matter how economically rational it is at the whole system level, every council leader that sees their region losing out to wherever the Local GDS is based would resist and argue against it.

BUT – and I think it’s a big but – none of that complexity should take away from one critical point in all of this. As a sector we have to bite the bullet and whole heartedly commit to an open standards based approach – seeing that through in the face of all the challenges and complications that are involved. Insisting that all of our systems can exchange data openly and that standard schemas and protocols are being used, begins to tackle the ability of councils to migrate towards flexible, agile solutions that meet user needs, and opens the door for considering collaboration and co-ordination across the sector.

Standards bodies have a part to play in this, but it’s really important that people in the sector stand up and get deeply involved – so it’s brilliant to see @localgovdigital people like Dan Blundell @danblundell and Ben Cheetham @_BforBen working with folks from GDS to find ways to share assets and form a community around practical implementation of common open standards.