An example of a service roadmap for a Housing Association.

“A roadmap is a plan that shows how a product or service is likely to develop over time.”

I’ve been scouting around for service roadmaps in the context of Housing Associations, but couldn’t find anything. So.. I’m chucking this out into the public domain in case it’s of use to anyone else.

This is hugely inspired by a GOV.UK post on developing roadmaps which you should really go and read if you’re interested in this sort of thing: https://www.gov.uk/service-manual/agile-delivery/developing-a-roadmap

This is my rough around the edges, slightly adapted take on roadmaps in the context of social housing. Thoughts and comments welcome.

What is a roadmap?

A roadmap is a way to visually communicate how a service might improve over time. It’s a statement of intent rather then something set in stone. It’s designed to be flexible to accommodate emerging priorities.

Why do you need a roadmap?

Historically, we tend to frame larger blocks of improvement work as projects. In my experience, this can be problematic because projects tend to be singular isolated fixes and are often disassociated from the broader end-to-end view of service delivery.

The scope of a roadmap is the entirety of a singular service. It’s an iterative plan to achieve the overarching vision of where the service needs to get to. By organising work in this manner, we ensure that energy is expended in the right areas, at the right times, improving the things that deliver the most value to the people who use the service.

Who is the roadmap for?

Ideally it should be open for everyone to view so they can see how the service intends to improve in the future. That means making sure it’s jargon free and easy to understand for the widest possible audience.

What does a roadmap look like?

Here’s a totally fictional roadmap based around a social housing repairs service.

A fictional roadmap for a repairs service in a Housing Association.

How does it work?

The blue blocks of work are called missions. They can be thought of as the things you intend to do to meet the vision of the service. If you use Objectives and Key Results in your organisation, you might link these to missions. Typically the are delivered in quarterly blocks. The number of simultaneous missions happening within a quarter would likely be determined by the capacity of the teams delivering them. Beware too much simultaneous work in progress which will stop you from completing things!

The red blocks are Firebreaks. Firebreaks are short periods of time (a week) between missions. Delivering change can be exhausting, so the aim of the firebreak is to allow people to rest, recuperate and pursue other unplanned personal projects that might also add value to the service.

The roadmap should be reviewed regularly, no later than quarterly intervals. Ideally it should be a singular living document that everyone refers to so that they know what’s being worked on and how it will improve things.

What do you use to create the roadmap?

Whatever you’ve got to hand and/or whatever you can easily share with other people. Some people use Excel or Trello. Some prefer to opt for physical rodmaps written on whiteboards or rolls of paper. I knocked the above example up in Google Drawings. The benefit being that it’s easily editable, shareable and doesn’t require any installed software.

Can I get a copy of your fictional roadmap?

Yes.. here’s a link to the original: https://docs.google.com/drawings/d/1WNgjaLibBRpJeZ9yhR5jgDfSAFEbaIETtYnvcF81524/edit?usp=sharing