I thought it would be interesting to share how we went about making the GOV.UK roadmap for the 2017 to 2018 financial year. So in this post I’ve distilled the process down to the main things we did, and are doing.
So, here are my 8 natty steps (they aren’t necessarily in order or separate from each other):
Think about history and context
Our work is influenced by the government’s Transformation Strategy (which we helped shape). We also published a long term vision for GOV.UK back in March 2016. We wanted to make sure our roadmap acknowledges both of these things. We also wanted to connect to work in other GDS programmes, like GOV.UK Notify, registers and the Services programme.
Get all the possibilities in one place
We flushed out everything that could be considered as part of our roadmap and thought about how to assess them. I found it useful to write up cards that answered these 5 questions:
- What is it?
- Why should we do it?
- Who are the primary users? (and how many are there?)
- What sort of team will we need? How big?
- How will we know when it’s done?
The ‘why’ is both the user needs (start with user needs!) and technical and functional considerations. Broadly speaking, if I can’t provide good answers to these 5 questions then I’d be likely to scrap it. Talking these through with the team meant we could prioritise rigorously, while still taking our gut feeling into account. Judgement is always a part of good decision making.
Know what’s going on in government
We worked out which upcoming government events are likely to need our support. That might be something like helping to publish the budget, or work related to Brexit. Other ‘must do’ items include commitments we have made, such as the Open Government Partnership. These things form the backbone of our roadmap.
Group into themes
We thought about how each card fits into themes. For example, lots of GOV.UK’s work in the next financial year is tied into expanding the content operating model work over the coming years so that it’s easier for users to find, understand and trust information.
As the themes emerged we could turn these into objectives. From objectives we were then able to begin articulating what the single goal for the year would be too - making the single domain work harder.
Find out what colleagues are thinking
It’s not my roadmap, it’s GOV.UK’s roadmap. To make sure that it’s collaborative there are things we did, and do, to know how people are feeling and collate their ideas, such as:
- a survey to find out how everyone felt about the current roadmap and processes associated with it, and what they wanted to see in the coming year
- a retrospective with GOV.UK product managers on the 2016 to 17 financial year
- quarterly roadmap reviews with delivery managers, tech leads, product managers and other owners of parts of GOV.UK
- fortnightly catch ups where we talk to team leads about their work, what they need and how things are going
- constant roadmap reviews by me - comparing it against what we intended to do, and what we actually ended up doing
- keeping in touch with colleagues across government and across GDS
analysis of our online feedback mechanisms, like Feedback Explorer and ZenDesk
Think about ways of working
We thought about how specific we needed to be, or wanted to be, about items on the roadmap. We also thought about structures for the year, and what implications they would have.
We decided on a structure of 4 mission phases of about 11 weeks each, interspersed with 3 firebreaks. We decided we also needed to start the year with a 2 week buffer in which we’ll solve small, known problems and build tools that we need for the roadmap ahead. It’s also a chance for new teams to get to know each other and to recharge their batteries before the (potentially) intensive work begins.
We’ve also blocked out time that’s less specific, or covers a wider subject area, like how our publishing applications work for users. As we approach those blocks of time, we’ll identify the problem we want to solve, and why it’s important - but we won’t stipulate how that should be solved; the teams can identify where they can have the most impact once we’ve understood the problem.
Our firebreaks are deliberately short - just one week. Firebreaks are a chance for everyone in GOV.UK to decide what they want to work on. They provide time to stop, and refocus on the next mission. Teams will be challenged to make the smallest, most valuable improvement possible in the time available, and build sustainably. Beyond that, the programme team will stay out of it.
Scope will be a big challenge for us next year. Missions will stop and start, so we need to spend time thinking about how to keep an eye on scope creep. At all times the scope must balance support requirements with maintaining good technical health. We’ll celebrate deleting as much as we celebrate shipping. Each 11 week period must be complete and valuable in and of itself without needing ‘just another thing’ to be done.
Another important change in our ways of working is that the performance team will, at the start of each 11 week period, work with all of the teams to help them with a joined up and rigorous approach to how their mission is measured. This is to ensure we’re thinking about measurement from the very beginning and so that the performance team understand the wider picture. As every mission is measured, that contributes to the measurement of an objective, and from that we can measure the impact of our work overall - against our goal - for the year.
Review the approach so far
Once we’d done all of the stuff outlined above, we took time to step back and think about what was emerging. That gave us a chance to think about other ways of doing things, catch things that may have been overlooked and consider implications a little more. That’s things like focusing on what work is dependent on other bits of work, and if our groupings of work has affected the vision. We also looked at who would benefit from each piece of work and if that felt right. The more time we spend thinking, the better we will be at sharing our plans, because we’ll be more confident about our intentions.
Have a healthy dose of realism
An essential step! We may have thought we’ve arrived at The Roadmap, but have we considered everything? Have we got enough people? Have we got the right skills and experience to do all the things we want? What does it mean for how the organisation is structured? If we need to make changes, then lots of time needs to be given to how we’ll do that and the implications of it - a whole extra phase of planning. We did things like hypothetical mappings of people to missions, we ran a survey to find out what things people want to work on, and made sure the right people are in the right places.
With the proposed structure in place, the need to invest in team health and happiness whenever people join or leave a team became clear. Our hope is that, by making it explicit, we invest more energy into it.
An important part of this phase of roadmap planning is remembering that before any of this work, we must support and maintain GOV.UK - the ‘business as usual’ work. We did analysis of support volumes and types, and thought about ways of maintaining standards without the need for standing teams throughout the year to own bits of the platform.
We’re going to move to a structure where certain parts of the platform belong to product managers’, they’ll move with the product managers as and when they move teams. That means we retain the knowledge and big picture continuity of products. However, it also means that we’ll have to address any risk that comes from having single points of failure - like having only one or two developers who can work on a particular application.
Share and iterate
We share our thoughts early - showing the draft roadmap and what we want to achieve. It’s prefaced with a strategy so people can see what the plan is and WHY that’s the plan. This process of sharing should also be part of including people in what’s to come - people should feel excited and energised by the direction! Based on the feedback, we iterate, iterate, iterate…
We know that by the time we’re a few months in, things will have changed and priorities on the roadmap will shift. That said, it’s really important to plan so that we have a clear direction and base from which to make future decisions on.
It’s a solid intention, but not irreversible.