This post is based on a talk I gave earlier in the year about how we are using roadmaps in government.
Many civil servants are familiar with project plans. A project plan is a great tool for planning time, scope and cost when you have a high degree of certainty in your users, their problems, and your solution.
However, the development of services often requires us to operate in areas of uncertainty and work with agility. Roadmaps can be used at the team level, service level, and organisational level. They are great tools for making strategic decisions in spaces with low certainty. We can use them to maximise the value of public service for our users. We can set goals for our teams, reprioritise quickly, and work with senior leadership teams.
Here are 3 tips for getting the most out of roadmaps for your service from MOJ Digital and Technology.
1. Focus on value
A core principle of agile and lean theory is that products should seek to maximise value. Products should not be judged solely on their adherence to cost and delivery schedules, but also on their delivery of value. Product managers are responsible for maximising the value of products. They think about value at three levels:
- vision: what’s the big improvement in life for your users in the future?
- strategy: what are the incremental steps towards the vision?
- tactics: what are the actions that need to be taken to complete each of the steps?
Roadmaps help us to work on the strategy for maximising the value of our products, breaking the vision down into incremental steps.
Your roadmap needs to take into account value for your users and value for your organisation. The user research community leads the work to define value for users, and the business analysis community leads the work to define value for your organisation. If you define the value of your service then you can prioritise the development that is most valuable.
2. Roadmap services (not solutions)
Focusing on value requires us to start being passionate about problems, not solutions.
Our organisation, portfolio and delivery teams all need to be thinking in terms of services, rather than solutions. But what does that actually mean?
Louise Downe, Deputy Director of Service Design and Standards at GDS, suggests that calling something ‘Statutory Off Road Vehicle Notification (SORN)’ leads to a focus on transactions that serve the needs of government, not users. To a user, a service is simple. It’s something that helps them to do something – like learn to drive, buy a house, or become a childminder. It’s an activity that needs to be done. ‘Learn to drive’ describes a service. ‘Statutory Off Road Vehicle Notification (SORN)' describes a transaction. Why is this important?
Roadmaps are new for lots of people, who may be used to project plans that focus on solutions, milestones and costs. If you name your service after a solution then you’ll tend to frame the conversation in terms of a solution. If you name your service to describe its value then you’ll tend to frame the conversation in terms of a user and their needs, and focus on value. This sets the conditions for a roadmap to be truly useful.
3. Use your roadmap to set goals, not tell a team what to do
There are a lot of blog posts out there on roadmaps, with the GOV.UK team being particularly great at sharing their insights within government. Posts vary a lot in terms of things like roadmap format, or whether or not to include dates, or whether or not to include budget.
The important thing to remember is that there’s no right answer; do what’s best for the users of your service, your team, and your stakeholders. One thing everyone tends to agree on is that roadmaps should focus on goals, benefits and objectives. And, they should be used to challenge teams, rather than telling them what to do.
Objectives and key results are used in large organisations, and can be set to apply at every level. This makes them well-suited to building public services within government.
Jock Busuttil, my predecessor as Head of Product for Ministry of Justice, recently shared a good post about roadmaps in which he also talks about setting goals. He suggests that the goal of every step of a roadmap is to test a hypothesis that doing something will improve the value of a service.
Share your roadmap
There’s a full set of roadmap principles coming soon from the cross-government product community. One of these is likely to be that we should share our roadmaps publicly. So, why not start now? Please share your own roadmaps, and roadmapping tips, in the comments. We can use these to learn from each other how to get better at setting goals for our teams, and help improve public services for all of our users.