Reflecting on the 2021/22 roadmap for BC Government’s Platform as a Service

Shortly after joining the BC government, I led my team through a roadmapping exercise that earned a lot of attention in my work area, so I’ve been wanting to share our process for a while. This was brand new to me — roadmapping is something I’ve contributed to but never led — so I used a mixture of advice (mostly from gov.uk blogs) and creativity to come up with my own approach.

A bit of background: I work on the private cloud Platform as a Service (part of the BC Dev Exchange.) Our platform enables development teams in the BC Government to deliver modern, rapid and secure digital services. As of right this moment, our platform hosts 313 applications across 17 ministries. Our platform uses a technology called Openshift which I’ll refer to here.

How we built our roadmap

1. We started with users needs by examining user research (both old and new.)
2. Our team brainstormed everything we could do to meet user needs and improve the service for the people who use it. This resulted in over 400 sticky notes, so we refined these down to about 33 themes of work, which I further classified into 4 workstreams (you’ll see these below.)
3. We took those 33 themes of work to our developer community and ran a card sorting exercise, where we had both our team and our users group the items into High, Medium, Low and Don’t Do categories. We put a limit on the number of high and medium categories. We had about 70 responses, approximately 40% of our user community. You can see what this looked like below.
4. We used this data to plan the work: Items that were frequently ranked as high priority were started in the first three months of the year, followed by the medium items and finally the low ones.

You can view the roadmap here.

This is what our card sorting prioritization exercise looked like:

Did we do all we set out to do?

Here’s a list of all we set out to do and details on whether we managed to achieve it this year.

Operational excellence

1. Offer multiple tiers: YES ✅ we rolled out a gold cluster for critical apps
2. 99.5 uptime for silver: YES ✅ You can view our status history here
3. 99.95 uptime for gold: YES ✅

Build security across platform apps

1. Provide pipeline templates: ✅ Yes
2. Logging tool: ➡️ Working on it now
3. Role-based access control: ➡️ Working on it now

Make our service easier to use and understand

1. Improved tech docs: ➡️ We’re working on this now
2. Simplified web presence: ➡️ We started this work in October but it’s a big project. We have something built but still need to test it further with users.
3. Improved onboarding journey: ➡️ We’ve completed a lot of research and come up with improvements; they’ll launch with our new website
4. Enhanced training: ➡️ We’ll be iterating on our current training and launching a new course

Engagement and support

1. Clear support model: ➡️ We’ve made improvements to this which will be launched with our website. We haven’t fundamentally changed the model, but we’ll be more clear about it, and what our users can do when they need assistance.
2. System of continuous feedback: ❌ No. Although we engaged with users and our community regularly throughout the year, it wasn’t continuous feedback. We still need to figure this out.

Other things we did this year

In addition to our roadmapping priorities, we also took on :

• We rolled out several different tools to help our teams with security of their applications: Vault, ACS (Advanced Cluster Security), Sysdig and Artifactory. We also implemented ArgoCD and worked on our CI/CD pipelines and cluster automation.
• We built or made important improvements to in-house tools, namely an App Assessment dashboard and our platform registry
• We migrated our platform from Openshift 3 to Openshift 4 and completed nine Openshift upgrades
• We ran our Openshift 101 training 12 times to around 300 participants, and hosted regular community demos.
• We ran five qualitative and five quantitative research studies to better understand the needs of our user, and created a feedback and codesign panel.
• We expanded our team to include content and IA skills, so we could finally take on the important work of building our web presence

What went well with our roadmapping process

The real value in this roadmap was the simplicity and clarity. We’re a very technical team, and this visual makes our service clear to almost anyone, even those with no technical expertise. I think this is the main reason this roadmap got so much attention at the executive level.

I think the clarity also helped our team see the direct connection from what we do to what the outcome is for people who use our service. This draws a line between us and our users, creating more empathy and understanding.

Finally, it gave us some overarching things to work towards. We could see how the small things we all did fed into a bigger, more strategic picture of where we wanted to be.

What we can improve on

I’m the first to admit that our roadmapping process and visual are not perfect and there’s a lot we can do differently. For instance

• Putting it together was more labour intensive than it should have been. I had our team think of all the work we could do this year, then I themed these into 33 deliverables. It was a lot of work for everyone. This year, I’m taking the opposite approach: I’m having the team think up the goals, and we’ll figure out the work after.
• We should offer our users the chance to contribute their own ideas. Instead of having the user community pick from a list of things we’ve already decided, I want to open it up more and let them contribute their ideas.
• Mural is not accessible right now, and it’s a workshop tool, not a design tool. When I built this last year, Mural was the only visual tool I had access to. But I want to explore different, more open and accessible options. Please let me know if you have any suggestions.
• Less time and attention on visuals, more on content. This roadmap became very popular in my division, which is great, but I worry the focus has been on the visuals and colours, rather than the content.
• Make it open! I haven’t shared this roadmap outside of BC gov until now, and that’s not on. Roadmaps should be public, open to critique and questioning.
• And lastly, this one is hard for me to say, but this didn’t actually change how we work much. It didn’t affect how we plan our sprints, we didn’t integrate it into our tickets, which just leaves me wondering … what was the point if it didn’t change our day-to-day work? This lack of integration also made it difficult to track our progress, as we couldn’t just pull items from our Zenhub board.

Onward

We’re currently working on our new roadmap — we’ve started gathering ideas from our team, and next we’ll be engaging our community.

I always welcome questions and constructive feedback, so if you’ve been thinking about your own roadmapping process or want to share your thoughts, please get in touch on twitter or by email.