Raising the visibility of our roadmap and making it open to participation

[psd]

We want to make our roadmap items: prototypes, projects, services, missions, activities and definitions of success publicly accessible. This is so we can:

• raise the visibility of our work inside and outside our organisation
• help users and stakeholders understand what we're working on particularly for users of our data design service who work on policy, with grids and timelines
• lower the barrier for others to help us by participating in our design decisions one of our principles is to be inclusive when designing
• reduce the burden on the team answering the needs of governance within our organisation
• meet other external governance, such as the digital service standard.

We need to find the users and research what they need to know.

In the meantime, what exemplary roadmaps should we try and emulate?

[psd]

Neil Williams gave a talk at mind the product on early experiments in roadmapping at GDS also on the GDS blog PDF

The GOV.UK 2016-17 roadmap became much more GANTT-like. I'm not a fan of how certain this feels, but we could make a similar visualisation to help show a timeline of each project.

The 2017 vision for GOV.UK looks like something we should emulate.

The 2017-18 GOV.UK roadmap has a stronger vision and narrative, but still uses product plan.

[psd]

@jamiearnold has some great posts on the practice behind creating a roadmap:

Everyone loves a roadmap explains why we should work at this, and seven questions to build a roadmap has a great approach for how we can develop our plan:

1. What are we trying to prove or learn?
2. Who are the users?
3. What are we operating?
4. What are we saying?
5. What are our assumptions?
6. What are the dependencies?
7. What capabilities do we need?

[psd]

Richard Pope showed a roadmap in his anatomy of a project space:

[psd]

Here's the 2018 Q3 roadmap slide we made for internal governance purposes:

We were particularly weak on how we'll measure outcomes during our alpha.

[psd]

@yahoopete talked about his team's experiences running an open backlog when delivering inside-government

[psd]

We should turn https://digital-land.github.io/ into a roadmap service, built using data and content in this issues list and repository, a place to find all the things:

[psd]

More sketching about being clearer on our strategy:

Being clearer how the strategy is how we get from where we are to where we want to be. Roadmap seems to be used for quarterly planning, which is a small part of the story we should tell for good governance.

[psd]

The GOV.UK transformation programme had a dashboard of projects and their status:

https://webarchive.nationalarchives.gov.uk/20150204082752/https://www.gov.uk/transformation

This has been archived in a more vanilla format: https://www.gov.uk/government/publications/gds-transformation-programme-2013-to-2015/digital-transformation-programme

[psd]

@Ellayanor pointed at architecture decision records as a way of recording design decisions: https://crown-commercial-service.github.io/ReportMI-service-manual/#/decision-records?id=product-decision-records

[jakemulley]

Examples: Making Monzo, Office 365 Roadmap

It's definitely worth having a public, simple roadmap that showcases a high-level overview of what the team is doing similar to the examples above, sticking to three stages, using non-commital language, such as "planned", "in progress", and "done", rather than Microsoft's "In development", "Rolling out" and "Launched" to help us when priorities change. The terms used by Microsoft are very commital and are linked to Q* release dates. Some work has already been done on Digital Land's project pages.

The items in the roadmap stages can then link to a more low-level descriptive piece and can further provide a way for those who are engaged in our work to publicly discuss and comment on.

To help raise visibility of our work, both inside and outside our organisation, we should steer clear of using something like GitHub to track projects, as it is developer-centric and it may be worth using more common software, such as Trello, which may be easier for non-technical people to use.

A key piece around this work is absolute transparency, including documenting decisions and talking openly about what work has been prioritised, and why we're focusing on it. This should include things such as user research and their outcomes, in particular helping Local Authorities or other government departments, devolved or otherwise, who may be looking to do similar work to Digital Land. This can also aid with helping users and stakeholders understand what we're working on and why, alongside lowering barriers for others to get involved.

It is also worth including community guidelines around this to help keep discussions topical and suited to needs of those both in and outside the organisation.

[psd]

Martin Weigel's Strategy needs good words has great advice on writing a strategy:

1. Know your audience
2. Make action your goal
3. Narrative demands jeopardy
4. Structure creates narrative
5. There is only momentum or useful description
6. Narrative travels in one direction only
7. Make no assumptions
8. Be the ruthless editor
9. Try not to create in slideware
10. 10 Use small words to express big ideas
11. Don’t hide behind jargon
12. Make time for deep work
13. Read good words

[psd]

This thread from Jana Bastow beautifully argues against timeline based roadmaps: https://twitter.com/simplybastow/status/1168531672335343616

I particularly like the prodpad vision template:

raising objectives:

the time horizons:

and the lean road-mapping canvas:

[psd]

GOV.UK has published: https://www.gov.uk/roadmap

[psd]

The GOV.UK PaaS team used trello for its roadmap: https://github.com/alphagov/paas-roadmap

[psd]

Wikidata has a development plan: https://www.wikidata.org/wiki/Wikidata:Development_plan

[psd]

DARPA has The Heilmeier Catechism for new projects, good questions for a roadmap to answer:

• What are you trying to do? Articulate your objectives using absolutely no jargon.
• How is it done today, and what are the limits of current practice?
• What is new in your approach and why do you think it will be successful?
• Who cares? If you are successful, what difference will it make?
• What are the risks?
• How much will it cost?
• How long will it take?
• What are the mid-term and final “exams” to check for success?

[paulmsmith]

Simple Analytics have a nice open road map:

It is a different model from us but I like how it is linked to tickets in Github.

https://simpleanalytics.com/roadmap

[paulmsmith]

Ben Holliday's 'Framing the problem' questions have been a go to set of questions for any work I've done.

[paulmsmith]

The GOV.UK PaaS team used trello for its roadmap: https://github.com/alphagov/paas-roadmap

I like the idea that whatever we use is part of our workflow and adds little-to-no additional burden and has a low barrier to entry.

So a Trello board that our sprint board could reference might work. Trello is a lot less scary and technical looking that Github too and can be styled slightly too.

[paulmsmith]

@stevenjmesser shared this on Twitter re: roadmaps:

[stevenjmesser]

@stevenjmesser shared this on Twitter re: roadmaps:

Thanks for referencing it, @paulmsmith! I wrote this on open collaborative roadmaps in case it's helpful.

[paulmsmith]

@stevenjmesser Awesome! Thanks for writing it!

[psd]

I really like how GOV.UK Pay and GOV.UK Notify frame their roadmaps as upcoming features. This clarifies the reason for a public roadmap is to help users and stakeholders plan and make decisions based on the intent of the team.

[psd]

James Higgott on creating the NHS website roadmap

[stevenjmesser]

Funny to see some of my bumpf up there 😅

If we use GitHub Projects to manage our work, it has a roadmap view of in-progress and upcoming work.

[stevenjmesser]

I’ve created a platform roadmap in GitHub Projects and signed up to GitHub’s public beta for sub-issues and types. This will allow us to create issues for each of our OKRs, and teams can create sub-issues for their work – linking the work done on teams to our OKRs. We can then link the objectives on our roadmap page through to the work inside GitHub Projects – proper working in the open.

[stevenjmesser]

I like the idea of using GitHub Discussions more too, @psd, thanks for moving the issue here. For some aspects of our work, we could start a discussion and invite people inside and outside the teams to comment.