I wrote a couple of articles in August. They’re part of my ongoing efforts to demystify digital and leadership work.
I wrote an introduction to agile for people who work in charities (or anyone really), for Charity Comms.
I wrote about leadership skills for digital practitioners in the public sector (or anywhere really), for Think Digital. I’m running a tutorial on this topic at UX Cambridge later this week, with Ade Adewunmi.
Sarah Jackson of Kestrel Copy and I have developed a training day to help charities and non-profits do excellent digital project management. We ran a pilot of the course in June and we’re planning to run it again in Autumn.
The course covers how to
- carry out internal research and review your existing site
- set website objectives and choose the best performance metrics
- get to know your users, engage your staff, and keep your stakeholders happy
- choose the right agency, and know what red flags to look out for
- make the most of your budget and stay on schedule
- use Agile, user stories, wireframes, and develop your minimum viable product
- carry out a content audit and make a realistic content migration plan
- steer clear of launch day panic.
It was really rewarding to do something in a new sector, and fun to work in collaboration with Sarah. People said they found it useful and gave universally positive feedback. My favourite piece of feedback was
“Really enjoyed it and found it very useful. Met my goal of feeling confident about having to take on quite a bit of large digital projects in future.”
It’s nice to think that the day helped people feel more confident about their jobs, and as a result some charities will have better digital delivery in future.
Dave Briggs wrote about the Department of Health (DH) Digital Team’s work on a digital passport and asked for feedback. It’s part of their work to increase the digital capability of all staff in the department. The aim is to: “equip [DH’s] people with the confidence they need to be able to do great work, using the best tools and approaches available to them”. This is my feedback.
I really like the idea of having a clear set of digital things everyone is expected to know and do. I like that it is a simple list. I think it covers a sensible range of topics and I like that it focuses on useful things people would need to know to deliver their objectives, rather than learning about digital for its own sake. One of my bugbears is the attitude that digital isn’t something you need to plan, monitor or involve yourself in the delivery of, it’s just something that you don’t give much thought to and chuck over to an agency. The passport shows that this isn’t the case.
There are three things I’d change, though.
1. Put users first
This one might sound semantic but is really important to me. The line about users should come before agile. If you understand your users, you have a chance of doing a good project without using agile (though I’d recommend you do work in an agile way). If you don’t understand your users, you might as well go home, whatever way of working you choose.
2. Shift the focus from understanding digital, to being able to think and talk about how it can be used
Lots of the parts of the passport are about ‘understanding’ digital. I think it needs to go further, from understanding digital to thinking and talking about it. In my experience, many people are easily able to understand digital in principle, but don’t know how to talk about it or how it can be used. This limits their confidence. I’ve had many conversations where colleagues eagerly agree that they “need to be more digital”, but it all gets a bit uncomfortable and fizzles out when the digital people start talking about it in more detail, or suggesting ideas, and the colleagues can’t take the conversation, and so the project, further.
3. Emphasise being able to make digital delivery happen
The list talks about getting support and guidance inside and outside DH. I think this could go further to equip people with a bit more understanding of how they can make digital delivery happen e.g. in-house digital team, suppliers, what you might be able to start doing within your team. This might help shift the idea that digital is something you automatically put out to tender, or that it’s something only a few people within the department can do.
My second and third suggestions make the passport much harder to achieve and teach. But I think they would make it more impactful.
Good luck to Dave and the team in refining and using the digital passport. I’m looking forward to seeing how it develops.
Earlier this week Policy Exchange published their report Smaller, Better, Faster, Stronger: Remaking government for the digital age. The report argues that the government of 2015-20 – whatever its colour – should do all service delivery online, and that Whitehall needs much better data and digital skills to make this happen. I had the pleasure of working with Policy Exchange on the report, debating ideas and making sure they got what they needed from GDS to understand what we’ve been up to.
Here I will say more about an idea that the report glances at but doesn’t quite land upon. It’s the idea that digital gives us tools and ways of working that are applicable outside building digital products and services. I will start by pulling out that points at which the report’s authors Chris Yiu and Sarah Fink do glance at this idea. I will then look at some of the recommendations, and explore how digital tools and ways of working have been helpful in work I’ve done that isn’t about digital products and services.
[Warning: this post was banned from the GDS blog for being too long and waffle-y. I’ve tidied it up but it is still too long and waffle-y. I wanted it to see the light of day though, so here it is].
Following the breadcrumbs
The report makes it clear that digital is about people not technologies: ‘this is really a story about people, leadership and organisational change’. I couldn’t agree more.
The report goes further than Baroness Lane Fox and GDS’s words ‘digital by default’ to say that government should be ‘digital, full stop’. To take this to its logical conclusion, government won’t even need to say ‘digital by default’ anymore, because government is just digital. There wouldn’t be a Government Digital Strategy, there would just be a Government Strategy.
When these three points are put together like this, there is only one conclusion for me – that digital tools and ways of working can reach deep into the operations of government, beyond work that might seem to be digital.
Now I’d like to say something about my experiences of using digital tools and ways of working to do work that isn’t primarily about digital. This is work that is about people who aren’t online, and work that is core policy/governmenty stuff.
Digital -> open
One recommendation of the report is for a civil service directory, so that people can find and talk to policymakers about policy they are interested in. It’s really important to me that my team and I are visible for people to talk to us about our work. But we are using existing channels to do this rather than building a new one. We do this by blogging on the GDS blog, by being on Twitter, by being at relevant events/debates, and by proactively talking to people and organisations who work in our area (getting digital services to people who aren’t online). My view is that the more conversations we have, the better the work gets. The Government Approach to Assisted Digital and the assisted digital market engagement are better for involving people who aren’t in government. We are working on being more present in discussions with people that are offline.
The report argues that government should do more with open data and open policy making. I interpret open policy making as involving the people who are experts in a particular area as much as possible in making policy, or outsourcing policy making to them. The Policy Exchange report itself is a great example of this. The team there are thinking, talking and writing about what could be next for digital government. As a result they prompt us at GDS to think about what could be next, so people like me working in government don’t bury our heads entirely in pressing matters like the digital service transformations.
Digital -> non-digital
In these two examples digital has prompted government to think about openness in digital stuff, or being open in digital ways. To take this a stage further, thinking about openness should then make us think about being open for things that are not digital.
We are starting to do this at GDS. My team and I are doing open policy making on assisted digital by commissioning the Helen Hamlyn Centre to develop and test prototype assisted digital services. Digital has prompted us to think about openness, and we have reflected this back on the subject matter of people who are not digital.
Iterating in digital -> iterating in everything
Reaching deeper into the ways we work, the report argues that government should apply ‘lean start-up methodology’, using data to iteratively refine services and products. I think we should also apply it to the everyday working we do in the Civil Service, whether we are working on services or products or other things.
For example, in the assisted digital team we do alphas and betas of things that you might not think of as products, like departmental requirements for market for assisted digital services. We developed a prototype within our team, worked on it with colleagues in other departments, discussed it with our departmental programme board, and now we are refining it further. Last week I wrote a minimum viable product submission to our Ministers, took views on the main points, structure and evidence, then refined it.
This may sound just like silly new words for drafts or outlines but is different is that we make a fully working – though early stage – product, then refine it. When I do a draft, I just end up with a meticulously structured introduction and a lot of gaps on the hard topics, though maybe that’s just me… This way I have to have the discipline of tackling the hard stuff first. The result is a better product, or at least getting to the end product more efficiently.
It also demands a better quality of attention from the people who you share things with. They aren’t getting a draft, they are getting a first-cut product. A subtle but I think important difference.
Ramble -> summary
At this point I should have a rousing conclusion but hey, I did warn you that this was long and waffle-y. The best I can do is to say that in summary, I think we should try using digital tools and ways of working in activities that aren’t about digital products and services. Doing this has made my working life better, and I think it has made the work I do better too.
My team at GDS – along with most of the rest of GDS – uses agile ways of working. What’s a bit different about our team is that a lot of what we do could be called ‘policy’. We are the only ‘policy’ team in government I have seen work this way.
I put ‘policy’ in inverted commas because I don’t think the word carries much meaning when it’s used in a general sense about the work of civil servants. When people say ‘policy’, I think they are talking about a bundle of things to do which include evidence, judgements, activities and products, which often have a false distinction from ‘delivery’, but that’s a story for another day.
I was chatting with Mike Dixon of Citizens Advice recently about how this is different to how other teams in organisations that do policy and research operate. Organisations like charities, think tanks, and research agencies, as well as government. He explained that many policy and research teams have moved to a matrix structure where teams form around projects rather than line reporting, and waterfall project management is the norm. In other words, the team structures have been made more flexible, but the project management methods haven’t evolved.
This means that policy and research products are specified upfront, then created over a period of months to match the specification, then delivered. By the time they are delivered, the specification might be out of date or significant changes might have happened within the policy topic, but the likelihood of such change is not accommodated within the project. This mirrors the shortcomings of using waterfall project management to deliver IT and digital services. Technology change makes the service outdated by the time it is procured and delivered, and the final service cannot easily be improved based on users’ feedback.
My experience has been that using agile tools helps circumvent this in policy and research environments. For example, my team is doing a project with the Helen Hamlyn Centre, part of the Royal College of Art, to research ways to deliver assisted digital support for digital by default services. Collaboratively with the design researchers, we have organised this project into two-week sprints. At the end of each sprint, there will be a new a set of concepts about how assisted digital can be delivered. The concepts will have gone through initial testing with potential users (or research participants or respondents as you might also call them). The best ideas will be developed further in the next sprint. And so on and so on, until after three months we will end up with a set of design concepts that have been tested with users and refined based on their feedback. The insight into user needs and preferences is gathered throughout the project, in dialogue about the concepts.
There is no final deliverable or big reveal at the end of the project. The outputs are the the concepts, the knowledge gathered in testing/research, and the materials used along the way. We at GDS get to see what’s being developed at the end of every two-week sprint, and the findings can immediately inform our work. Helen Hamlyn colleagues get immediate feedback from us and our views of how their ideas fit into the wider programme, and this informs the next stage of the research.
I’ve also found agile techniques to be useful for juggling priorities, allocating work within the team, and sharing limited resource across projects. Even better, the team is increasingly self-managing on matters like prioritisation – another side benefit has been the team getting closer and working more as a unit. After all, the unit of delivery is the team.
I will say more about that – and what using agile means for how we work together day to day – in other posts. I’ve also been mulling over policy and research projects from the past few years where I feel agile would have helped us avoid some scrapes. I’ll elaborate on that once I’ve found a way to talk about it that protects the innocent.
To be continued…