In June, I was approached by a new client: UK Trade and Investment (UKTI). In July, I filled in lots of forms for them and waited. I’m not very good at waiting. In August, I started work there as Head of Digital Services. My role is to set up a digital delivery team. We’ll build excellent services for UK companies that want to export and brilliant tools for UKTI staff. Over the 6 months I’m at UKTI we’ll take the first services through discovery, alpha and, if we go fast enough, beta. I’ve learnt loads from existing members of the UKTI digital team, who’ve been doing really valuable research and discovery work. There’s a big opportunity to improve the UK government’s trade services and I’m very happy to be involved.
I wrote about what I learned from working at GDS, what I learned from working at departments, and why we should keep getting better at digital government. People seemed to like it.
I went to San Francisco. It was lovely. I saw some big trees.
Code for America very generously fed me and let me do a talk to them, and I got to hang out with Brie when a few of them were in London a couple of weeks ago. I talked about the UK Government Digital Strategy, working with people who have lower digital capability, and how working in a department rather than at GDS has shifted my perspective. 18F people very generously talked to me while we drank coffee, which was also excellent.
These are my brief reflections a few weeks on, about the similarities and differences I found compared to my experiences doing digital government work in the UK. They are based on about 240 minutes of data, so take them with a pinch of salt.
These things are similar
- people are really keen to talk about their work and learn from each other
- there is a sense of excitement that these organisations exist and what they can do
- members of staff have been happy to make substantial changes to their careers to be part of it
- people are really ambitious about the impact digital can make on service delivery but…
- there is just too much to do and it can be overwhelming!
- there’s a strong awareness that digital government/civil tech are about changing culture and organisations as much as they are building digital services
These things are different
- I found less of an interest in being seen as global leaders in digital government/civic digital
- people talked very openly about the need for a diverse workforce, with sophisticated rationale for why this mattered, and what they were doing to overcome it – this is unlike anywhere I’ve done digital or digital government work in the UK
- the offices are much nicer
I’m pleased and proud to be part of an international digital government community. We are very fortunate to be able to turn up in each other’s offices, be welcomed, and get to know each other. Thank you to everyone I met, I found our conversations really inspiring and returned to London full of energy and enthusiasm. Onwards!
I’ve worked on calls off for the Digital Services Store from both sides – as a client procuring a couple of projects, and as an advisor to a supplier putting in bids. In this post I wanted to write up what I’ve learned about making good proposals. It’s based on things that I’ve seen and done that have worked, and things that I’ve seen and done that haven’t worked.
My view is that it is a shared responsibility of both parties to make it a good procurement. You need good proposals. And to get them, you need good requests for proposals.
In summary, if you’re writing a proposal, you need to pay attention to what you’re being asked, and be good at writing. If you’re a client, you need to explain very, very clearly what you’re looking for. Both these things sound simple but are hard to do. Whatever side you’re on, use opportunities to communicate in ways that aren’t writing.
I hope this is helpful. I would love to know other people’s views of what is good or bad. You can talk to me @rebeccakemp
For potential suppliers, my advice is:
1. Really tailor your proposal to what the client wants. This sounds very obvious and I imagine that all the people who wrote bids I’ve reviewed would say they had done it. But out of 5 proposals for a digital strategy I received, only 2 had done this satisfactorily, and none of them had done it to what I consider a high standard. At the very least, your proposal needs to include the phrases and words used in the call off (not just the client and project name). 3 out of 5 of the proposals I read in that procurement didn’t make much effort to do this. Frankly, I was a little insulted. To be a suitable standard, you need to show that you have thought about the requirement and built it into your proposal.
2. Make it easy for the reviewers to read. It’s likely that the person marking your proposal is doing a batch of them, without time to luxuriate over your individual proposal. So make it easy for them by doing the hard work to make it simple. Use headings and topic sentences. Keep appendices to a minimum so the marker doesn’t have to keep flicking between documents. If you are using appendices, make it easy for the marker to get to the relevant information, rather than them having to wade through your standard proposal slides. Write clearly. Get it edited.
3. Make it easy for the reviewers to give you marks. As much as possible, structure your response point by point against the requirements and criteria in the procurement documents request for proposal and marking scheme. Think of it like a job application. It matters if you get awarded 2 points or 3 points for each question, so make sure you’ve hit every point. The difference between and 2 and a 3 is frequently how much the proposal is tailored to the client’s project, which takes us back to point 1.
For people buying services, my advice is:
1. Be really clear about what you’re doing and what you want to buy. I thought I was clear in my digital strategy request for proposals. But the responses showed me that I hadn’t been. When I reviewed the documents again I noticed that the title of the project was misleading. Cringe. Filling in all the documents for the proposal is challenging, at least for me, especially when you’re not procuring digital development services. When I do the next one, I’m going to get more people to review it to pick up on my mistakes and make sure it’s really clear.
2. Do a webinar. You’ll probably be offered the opportunity to do a webinar for potential suppliers to ask questions. Do it. It will make you put your requirements into another format, like in my slide above. For me, having to explain it in a presentation made me communicate it more clearly. It will help people who prefer to listen rather than read. It also gives suppliers an opportunity to raise questions, which is important if, like me, you’re not perfectly clear about what you’re looking for.
3. Meet the supplier if you can. I was advised against this. In hindsight, it didn’t matter for one where the requirement was very simple, but I wish I had met the supplier for the other one. At the very least, I could have probed the suppliers more on their understanding of the project – which for the weaker proposals, was probably higher than their documents suggested.
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.
I have started setting up the endeavour currently known as Rebecca Industries during my weekends. I am going to run Rebecca Industries in an agile style, so I have set up my wall in The Penthouse (Rebecca Industries HQ) and on Trello. I was inspired by Emily Webber on the wall-at-home.
I have assembled a standing desk by placing a plank of wood on top of a stack of boxes which I euphemistically call My Archive. I hope one day to have done something significant enough that I can donate it to an international institution, but for now it’s just boxes full of essays I wrote for my masters and posters for club nights I used to run. Yes, my computer is very old. No, my Take That mug is not ironic.
I am collating the advice that people who have made the transition to working for themselves have given me. This is going to be a very valuable resource and I look forward to passing on my experiences to others in future.
And most importantly I have handed in my notice at GDS. It has been wonderful to hear from people they value my contribution to GDS and have enjoyed working with me. It is also wonderful that I will continue be part of the GDS family and involved in digital government in future.
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…
My super clever colleague Reema Mehta wrote a nice summary of how digital by default Government will meet the needs of users who aren’t online.
It’s one of the questions we get asked most often at GDS. I’m glad we get asked it often because it’s important and for me personally it’s something that makes working in government interesting. We don’t get to choose to only provide services to people who are able to interact with us digitally, we have to provide services to everyone.
An even shorter summary is
- assisted digital – getting digital services to people who are offline
- digital inclusion – getting people online so they can do loads of digital stuff
Though I’m glad we get asked this question, I’m not at all glad when I hear people say that government can’t go digital by default without 100% of the population being online. In fact it makes me cross because it is not true.
Digital by default means ‘digital services that are so straightforward and convenient that all those who can use them will choose to do so, whilst those who can’t are not excluded’. It does not mean ‘everyone has to use digital services independently so they have to all get online, else they won’t be able to access services anymore’.
There is a role government can and will play – along with citizens, the voluntary and community sector, and the private sector – to support and encourage people and organisations to develop digital skills. But going digital by default is not contingent on this.
The moral of this story is… you could have either one of assisted digital and digital inclusion without the other, but I’m glad we have both.