Monthnote September 2014

I’m writing this quite a while after the end of September. Ooops. My memories are vague, but through the four-week fog I remember spending many hours behind this door.

PHE door

At Public Health England (PHE), home of the door, September was a month in which lots of things came to fruition. We wrapped up the consultation period for changes to the team structure and roles. I reviewed the work Scott Turton, Nathan Flowers and Victoria O’Callaghan of SapientNitro had done with us on a digital strategy, and found it very good. The team worked on the ‘tail’ content from our transition of health protection content to GOV.UK, and diligently dealt with queries and suggestions from users.

September was my last month at PHE. I’ve handed the role over to Diarmaid Crean, who is now fully installed as their permanent Deputy Director for Digital. They are in very safe hands, and I can’t wait to see where Diarmaid and the team take it next!

At the anonymous IT company, my colleagues and I switched from making the case for being more digital, to figuring out how to get going. We’re basically setting up a start-up within the larger company, building on work some pioneering colleagues have been doing over the past few months. Fun!

My thoughts on the Department of Health Digital Passport

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.

Monthnote August 2014

August was quite the month. Here I define ‘August’ to include the first few days of September.

In my previous monthnote I wrote about the work of the Public Health England digital team to transition the Health Protection Agency website to GOV.UK. This month it came to fruition. We have switched off the HPA website, though it lives on in the National Archives, and GOV.UK is now the place to find health protection information. Over the rest of September the team will transition the ‘tail’ (lower priority) content. Mahesh and Suzanne have written more about what the transition involved. When the dust has settled, I’ll write about what I learned during this project.

This is an amazing achievement by the team. Liz made some delicious cakes to celebrate.


I don’t think I’ll ever get tired of typing in and getting re-directed to the PHE section of GOV.UK. For a few sweet moments I’m going to forget about the other 135 sites that need transitioning.

Elsewhere, I persuaded a major IT supplier to government to start delivering digital projects for public services, and doing it properly. Or more modestly (and accurately), I did a presentation the senior management bods said ‘yes’ to. I really hope I can be involved in the delivery of this, because the opportunity to have positive impact across central government is huge.

I also did a short project with NHS Blood and Transplant. My role was to support the digital team managers to start an ambitious digital transformation programme for blood and organ donation. Together, we built a roadmap for the next 12 months, including a timeline that works for the agile digital team and the waterfall programme management team, and people and budget requirements. I love planning, so it was fun.

Monthnote July 2014

July was all about the work of the Public Health England content team, who have been working their socks off to get our priority health protection content from the Health Protection Agency website to GOV.UK. I’ve been doing my usual stuff, which you can extrapolate from my previous monthnotes, but for this month let’s focus on the content.

There’s one place for all health protection content. Much of the content is there already and we will be adding the less-used, tail content over the next few months.

Health protection

You can browse infectious disease information.

Infectious diseases


And you can see all the information about individual diseases, for example ebola, together in collection pages.



Rebecca Industries Monthnote June 2014

It’s not even the end of June but I’m in the mood for a monthnote tonight.

This month at Public Health England (PHE), the team and I have:

  • Produced new content for GOV.UK to meet our health protection users’ needs (that one was definitely the team, not me)
  • Done the first half of our short, sharp digital strategy development, with SapientNitro (that one was mainly them too)
  • Welcomed new content designers and started recruiting a digital policy person to keep us in line
  • Taken feedback on a proposed new structure and expansion of the digital team
  • Written a long business case, proper Treasury style
  • Told about 1000 people to start with the user need
  • Said fond farewells to Alison Hill, deputy Chief Knowledge Officer of PHE and my boss, and Rachel Neaman, Digital Leader at the Department of Health. We will miss you!

I’m now going to be working at PHE until the end of November, which is brilliant news.


The picture is a portrait of my by two members of the team at PHE, in which I am waiting for all our 150 websites to transition. She’s got great hair but in real life, I look less patient.

In other Rebecca Industries activity, this month I took a week off to say goodbye to my Grandma and ‘happy 30th birthday’ to the fabulous Kat Kennedy. I also carried on with my work helping a big IT company figure out how to approach the digital government market, about which I will remain secretive.

Making good Digital Services Store proposals

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.

I'm better by slide

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.

Digital, full stop

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.

The report also says that digital will allow us to open up the operations of government, through open data but, more relevant for my work, through open policymaking.

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.

Agile policy and research

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…

What about people who aren’t online?

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.