Friday, 17 June 2016

What I learned from Standard Sprint #1

Standard Sprint #1 was two weeks of work from 6 to 17 June, to both produce guidance for the Local Government Digital Service Standard and to see if it's possible to work collaboratively, using online tools and resources.

Turns out it is.

Rewind back to the start of April and LocalGov Digital released the Standard, with help from over 60 councils and the Government Digital Service. The Standard contains 15 points suggesting how to build and manage good local government digital services. Whilst some points are fairly self-explanatory, for example:

Make sure that the service is simple enough that users succeed first time unaided.

others such as

Use open standards, existing authoritative data and registers, and where possible make source code and service data open and reusable under appropriate licenses.

are less so and some sort of guidance was needed. As of today, that guidance now exists and we'll continue to revise and add to it.

So what did I learn?

Collaboration needs leadership

The sprint was the idea of Julia McGinley, Lead Business Analyst at Coventry City Council and she was also the scrum master. She expertly facilitated the creation of 15 items of guidance, based on all the comments received.

Relying on organic collaboration is far less likely to produce something usable. Up until 6 June, over the two months following the publication of the Standard, we'd only created guidance on one single point, two weeks later we have guidance for all 15.

Collaboration needs a core team

Though tens of people contributed from all over the country, a core team at Coventry City Council did the work of creating drafts, reviewing all of the comments, redrafting and again reviewing all the comments to create the finished product.

At some point they'll be a Standard Sprint #2 and another council could very well take the lead, but the point is, this works best when the core work is part of a team's day jobs, even if it is for just a short two week period.

Communication is key

An obvious one, but there were daily stand-ups and weekly reviews via Hangout which were open to everyone. We tweeted regularly using #ssprint1 inviting people to join in and updated the website to keep everyone update on the Sprint's progress.

Scheduling and timeboxing helps

Stand ups were at 9am, longer reviews on Friday, we closed comments at 5pm on 15 June, the Sprint ran for two weeks. Putting times and dates on things focuses those working and contributing to get stuff done.

The digital tools are there...

We used Twitter, a Hangout, a Trello Board, 15 Google Docs and the LocalGov Digital Slack Channel. The digital tools we needed to do the work described in Makers Project Teams worked.

...but not everyone could use them

Not everyone away from the core team in Coventry could access the Google Docs due to their council's IT policy. At some councils officers had to work from home to contribute and one council officer even had to stand in a hallway at work to access the Hangout on his smartphone. There's a separate blog post in this no doubt, but in short, blocking these digital tools is hurting councils' ability to collaborate and therefore their productivity.

Huge congratulations to Julia and the team and Coventry for making this happen. You've proved that collaboration across councils to produce something for the whole of local government in a short amount of time can work.

I'm sure we'll put together a more detailed case study, to explain and sell the concept of digital collaboration, but for now, after a two week sprint, go and put your feet up, you've earned it.

Sunday, 12 June 2016

Defining transformation to a wider audience

For the past month I've been putting together a paper on the next steps of digital transformation, for the organisation I work for. I'm proposing we look at two capabilities and two business areas, and if approved I'll be writing more about it.

It's been a great exercise in gathering my thoughts and helping me to define digital transformation to a wider audience and how it fits into the bigger picture of service improvement.

Here's some of the stuff I've learnt or had affirmed:

Transformation, digital or not, starts with understanding the needs of the user through research. This should be obvious, but in local government too often I've seen "build it and they will come" approach applied.

It's unlikely a commercial operation would launch a new product without first researching the market, so why would a digital service be any difference?

A couple of years ago I wrote how the phrase "digital transformation" was hindering digital transformation.

People get it if you explain things using terms they understand. So for example, a discovery phase is somewhat similar to a feasibility study, except it's part of the project.  At LocalGovCamp this year someone told us that they explained continuous improvements as "scheduled maintenance".

As with most communication, you need to tailor your language for the audience and digital transformation is no different.

A discovery phase doesn't always lead to an alpha phase, or a digital service. Here's a good example of not delivering a digital service, where the discovery phase of a DWP project was used to improve their telephone service based on user need.

Yes, very often your discovery phase will conclude that a digital is the better, cheaper way to deliver a service, but your project should focus on service improvement, not digital.

Work to a single vision by agreeing a set of principles. Explain how they differ from traditional practice and give a practical example of what this means. I created these principles with the help of Ben CheethamJames Gore, and Rob Miller.

Use these principles this to evaluate where your each part of your organisation is in terms of transformation, where the opportunities are and where need more investment.

"Channel Shift" is term that's used less and less these days, It's from a past era when most websites just delivered information, not services.

It is still valid however, so long as it comes at the end of the work. Research and redesign what you offer your users, develop and launch your digital service, and only then look to promote it to users over other channels.

I hope this is useful and if your organisation is approaching a new phrase of transformation, I'd love to hear your insights too.

Thursday, 9 June 2016

Draft Digital Principles

On 9 June I published a draft set of digital principles and asked for comments. Ben CheethamJames Gore, and Rob Miller responded and I'm really grateful for their input.

The principles as they stand now are:

Traditional Practice
Digital Principle
In Practice
Consider face-to-face, email and telephone as the default channel for delivering services and information.
Consider digital as the default channel for delivering services and information.
Ensure digital and assisted digital are prioritised over traditional delivery methods and are included in service and communication plans.
Deliver digital services on a service by service basis to a varying standard.
Adopt a corporate, joined-up approach to delivering digital services to a national standard, focusing on user need.
Create a joined-up programme of change with strong support from leadership, and a cross-service team to break down internal silos.

Deliver services to the Local Government Digital Service Standard.
Conduct periodic mystery shopper exercises.
Capture, measure and act on user satisfaction and usage data for each digital service.
Extend existing methods to capture feedback for every end-to-end digital transaction, to all re-designed digital services.
Procure IT systems and develop online forms to support existing processes.
Redesign existing processes to take advantage of the efficiencies and improved user experience digital can provide.
New projects that involve public facing services should be led using service design principles.
Clearly define the desired outcome and the solution for each project from the start.
Clearly define the desired outcome for each project from the start. Discover the solution through user research, prototyping and user testing.
Where possible, projects that involve public facing services should follow the Government Service Design Manual.
Deliver all projects using Waterfall methodology.
Deliver projects using an Agile methodology, where appropriate.
Where possible projects that involve public facing services should follow the Government Service Design Manual
Duplicate existing functionality as part of a solution.
Re-use existing functionality and design as part of a solution and make sure capabilities and data can be re-used where possible.

Check if any of the capabilities, data and capacity to deliver the service already exist, and if they do, incorporate them into the new service.

Publish details of capabilities and data that are available for re-use.
Work alone to procure or develop and deliver services.
Work with other councils and partners to procure or develop shared digital services.
Seek to establish or use an existing working group through a peer network before developing or procuring new services.
Delivery to a defined project schedule, with a distinct end point.
Continue to develop and improve digital services in response to user needs.
Periodic service assessments, redesigns, audits and “healthchecks”, collating data from UX testing, analytics and usage statistics.
Focus mainly on the technology being developed or procured to deliver the service.
Focus on the team skills of the developing or procuring the technology to deliver the service..
Make sure the teams creating and delivering the service have the technical skills to understand how to build or procure it, and continue to improve it.
This blog is written by Phil Rumens, Vice-Chair of LocalGov Digital, lead for LGMakers and who manages the digital services team at a local authority in England.

The opinions expressed in this weblog are my own personal views and in no way represent any organisation I may have worked for, currently work for, might be thinking of working for, might not be thinking of working for or have never worked for. In fact having said that they, might not even be my views any more as I might have changed my mind so I wouldn't take any of it too seriously.