Weeknote 7 - 11 September 2020

On broadcast communications, our new website, turning problems into lessons, roadmaps and cross-government collaboration.

Broadcast communications

We already had good tools in place to help us when the COVID-19 lockdown took effect. Very quickly, thousands of Council staff were productively working away from our offices. Since then we’ve been making more improvements and rolling out more tools. Our attention was initially on individual productivity and then team working. We are already supporting large scale events that are approaching broadcast scale.

This week, more than 3000 staff joined in a briefing from the Council Leadership team to get an update on how we are responding to our big challenges. Some of these are well known (such as helping the people and businesses of Cornwall) but some big ones are new and uncertain (climate change, public sector finances and, of course, the effects of the pandemic).

COVID-19 has forced us to move these events online but, in doing so, it has improved them, even for people working in our offices. We can post questions and comments during the event or see what others are asking and give our support. The leadership team covered the most urgent and popular questions there and then, while the others will be picked up in on-going communications. I was really impressed with the way the event was facilitated, the direct way that questions were posed and answered, and also with the efforts of our teams in IS who make this possible.

Next week we will have another virtual cabinet meeting live streamed to the public. The agenda includes short-term and medium-term budgets so this will probably have a big audience.

New council website

The new Cornwall Council website

We have started the work to update our website. As well as keeping some of the technology up to date we are taking the opportunity to make it easier for people to find what they need. We are also applying leading practice and ideas from other councils and the wider public sector which includes the latest guidelines on accessibility. There is a specific blog about this.

This week the updated design for the main Council Website was handed over to our development team. The team have already been working on upgrades to the website features and can now add in the look and feel of the new design. The next big challenge is to also add in a cut down version of the web infrastructure. We will give our development team the same sorts of high performance and high security components as the new public website. Our small and private development environment doesn’t really need these components for its own sake, but using these components early means we can sort out any issues and learn lessons as early as possible.

We already use public cloud services for our main website but we are going to take this even further and make more use of the just-in-time and on-demand options that are available. There is quite a lot of work to do but the benefits appear in cost (turn off capacity when demand is low), quality (better, more realistic testing) and performance (turn on extra capacity at peak times).

Turning problems into lessons

We made a big change to one of our systems at the end of August. Overall, things went really well but there were some unexpected side effects which impacted some users and created a spike in calls to our service desk. This week we held a Change Implementation Review to walk through what happened and take away lessons.

We may never need to make the same change again but there were some improvements that are worth following up. For example, some users have created their own links and short-cuts which might break during a future upgrade. We need to think about what to do with these e.g. remove them, provide more instructions or make them an official part of the system. We also think the project team could have helped more when the spike in calls started. Some changes to our ways of working here might help with any release for any of our systems in future.

Roadmaps

We made progress on several of our Team Bumblebee¹ items this week, including the light-touch way we close projects and handle the on-going support and maintenance costs when we introduce a new system or make major changes. We also continued to look at how we can make our product roadmaps more useful.

There is quite a lot a consistency across the agile and digital community when it comes to things like backlogs² but much less for product roadmaps. Many of us think product roadmaps are useful and should be shared more widely but there are lots of complications. Different audiences have very different ideas about what a roadmap should tell them. Here are some examples:

• What time horizon is needed? Some want to cover a year or more and some are just interested in the next 8 weeks.
• What degree of confidence is needed before something is included in a roadmap? Some cover ideas and innovations that might never become a reality. Some expect the roadmap to represent a promise or commitment to deliver.
• What sort of engagement is needed? Some roadmaps communicate things that have already been decided and others are just a prompt for an on-going dialogue.

I am wondering if talking about roadmaps might actually get in our way as there is such a wide variety. Maybe there isn’t anything that can satisfy all of these demands. I would like to delve further into our needs and see what we can do to address them. Sometimes we might produce something that has “Roadmap” in the title but we might well have a collection of artefacts or activities, each fit for their particular purpose.

A word about a good cause

I’m continuing to work with a cross-government team to help people in the public sector learn about agile and digital ways of working ³. We are most of the way through adapting a Home Office course to make it generic. Next week, I’ll join the other coaches to walk through what we have and get ready for my first go at guiding a small team through the course.

Footnotes:

1. There is more about Team Bumblebee in a previous week note. ↩

2. See a previous post for more about backlogs . ↩

3. There is more background about this in a previous week note. ↩