January and February 2024 month notes
In the spirit of transparency and candour, the service transformation team publishes reflections on the what and why for the team.
Kelsey’s notes
When I started writing this post there was snow falling from the sky and the daffodils were just starting to open — a week later, folks are outside in short sleeves and the blossoms in full bloom. This mishmash of seasons is fairly typical for March in Victoria.
Fittingly, it’s been a typical mishmash of work for the Service Transformation Branch (STB) in early 2024. We’ve focused on sustaining momentum on digital delivery teams and explored what supports are needed to accelerate the work and build foundational capacity. Martha Edwards joined our team as the new Director, Strategic Design covering for Kevin Ehman in 2024. As always, having new folks join the team is a great chance to look back how you’re approaching the work and where you can improve (I loved Martha’s note on the challenges of onboarding via meetings in her First few weeks as a designer leader post).
Branch planning is in the air. Service transformation is something you work on from many angles in order to see progress — from hands-on digital delivery to creating the structures to support multi-skilled teams to thrive. And yet, this can sometimes make it feel like our team isn’t ‘making significant progress’ as we’re spread across so many areas and activities at once. I’m hoping our branch planning work in March/April can help shine the light on where we really want to see progress (and how then we’ll measure progress towards it). I’m hoping this process will help ensure we all have a clear line of sight into our priorities: where delivery remains the strategy and we have a tight list of supporting structures we’re working on that address a clear ministry service transformation need.
Delivery is the strategy
Our delivery-focused work has been rich and varied throughout January and February. It’s hit so many of the key areas of product management that it’s made me reflect on how we don’t provide great resources in the B.C. government to support new product managers in their roles. Stay tuned for a specific post that outlines the journey for product owners to research, plan, design, develop and launch digital services.
In the interim, a few delivery highlights from our ENV product team support:
- Defining the Minimum Viable Product (MVP) of the Compliance and Enforcement public complaints management tool. It was great to participate in a three-day in-person session with the team and drill down to what features needed to be developed, release timing and a realistic roadmap for launching a product to Conservation Officers in 2024. Shout out to the new product manager, Adrienne, for stepping into this role at a pivotal time.
- Building a governance approach and digital roadmap proposal to tie together the various Compliance and Enforcement digital services. This looked like working with Gwenda Laughland, the Executive Director for Regulatory Effectiveness and Sector Integration (aka compliance and enforcement wizard!) to present a path forward on these points to various ministry and sector audiences. We’re well on our way to building a foundation for a portfolio and product management approach to the full compliance and enforcement service journey (complaint, inspection, investigation, penalty and outcome reporting).
- Working with teams in the Climate Action Secretariat on service design to explore the current process for local governments and public sector organizations to report carbon emissions. How might these processes be streamlined and what tools could support better support data analysis and reporting?
- ENV uses a variety of regional boundaries for program operations and reporting. Henry dove into this space to understand the rationale for multiple boundaries (answer = specific operational needs), and identified opportunities to build data skills/processes that are agnostic of reporting boundaries.
- Supporting content approval pathways and organizational design for the CleanBC digital experience team (check out the refreshed homepage!).
- Sharing knowledge and approaches on how teams in the natural resource sector are engaging with Indigenous communities and what digital services they might, or could be using to support these efforts.
- Leading the ENV Digital Working Group, which includes representatives from each division, to confirm priority maintenance and enhancement work for ministry IM/IT overhead funding in the coming year (2024–2025). This included working with division leads to run their discussions where program areas identified key digital service needs, exploration of those needs and estimation of costs and finally prioritization. In future years, I’d like to see this process run alongside branch planning to more tightly link digital service needs to branch priorities and policy initiatives.
- Supporting governance conversations on shared digital products. A stand-out was an in-person workshop led by Alluvial Consulting and Openfield on roles and responsibilities that included a life-sized RACIS (responsible, accountable, consulted, informed, supportive) matrix.
- Ongoing advisory support for the Environmental Protection (EP) Digital Services team, and playing a very minor role in supporting discovery research for the integrated pest management certification and permitting service (the team did a great job exploring and scoping this work!). A few more thoughts on next steps for this work below.
A few bimonthly reflections:
How we communicate design work matters. And by ‘design work’, I mean both the process of doing service design or user research and the insights drawn from that research.
The EP Digital Services design team has been working through discovery research and pre-work on a few services (Site Remediation Services, Integrated Pest Management, Hazardous Waste and authorizations for waste discharge). This work paints the current state picture of how the services work and gathers together existing insights from staff or external users on pain points and what could be improved.
A few reflections on this process:
- Program areas are surprised about the amount of time it takes for designers to learn about a service and understand internally processes. There’s work to do here to understand why this is surprising for teams and how we can quickly building trust, show value for the team (not just the value of design) and align expectations for the work to be done. This needs to include breaking down what ‘working agile’ means from a program perspective and what they can expect (i.e. working in small increments, putting the time into research and not receiving a final product all at once).
- Design terms (i.e. discovery, pre-work, user-centred, systems-language) do not land well with folks who are new to the design process. We need to break down the jargon — and keep communications short and simple. A reminder of useful plain language apps like use Hemmingway to help with short and clear comms. I’m almost thinking that a TLDR; approach here is best.
- A standard visual or process on the design process can help guide program areas, but it needs to be lightweight and plain language.
- My role and others in design or digital delivery leadership roles need to help craft the narrative from a program-area point of view (i.e. what are the questions a program area might have, what will deliver value for them?). A initial sketch of the narrative before the story is crafted could help set the outline and then have the team fill bring it to life.
The EPD design team is continuing to work towards being crisp in communicating to program areas the what and how of design work. This has looked like outlining the steps in the design process, using plain language and presenting a visual roadmap of the design work that precedes technical development (i.e. actually writing code to build a new service). We’ve learned lessons on the impact of missing key steps in the process or when program areas don’t fully understand or embrace the agile design and development process. These learnings will only make the work stronger next time, though they have been tricky to navigate in the moment.
Procurement eats up TIME. Sometimes I think half of digital delivery is securing the right people and products/firms to support the work. Over the last month I’ve spent countless hours discussing the best procurement approach to find the services we need for a service and the procurement options needed to do so. For folks looking to grow their digital delivery skills, building procurement know-how is key. (and…it’s actually hard to find a single spot that lists all the procurement options available; I’m hoping to include this in the product management post).
Procurement takes time — which can slow down delivery and eat up staff hours and budget.
It’s a necessary part of government digital service delivery — we need to run fair and informed procurement processes to ensure vendors have equal opportunity to bid on government tenders. But, it’s also important to understand the impact of procurement on a service delivery when teams are making key strategic decisions. Decisions like: procuring SaaS or building custom applications, running a large-scale RFP for a large product team or breaking down services into small pieces to run alternative procurement approaches like Team with Us or Request for Quotes. Before you go too far down the rabbit hole, think about how long these processes might take (staff time), what procurement or legal services might you need to pay for (budget), what’s the likelihood you’ll actually end up with a successful vendor or contract (staff and budget) at the end of it all. When we’re trying to work in small, agile increments, big lengthy procurement processes are a big risk.
De-risking procurement can be fairly easy on smaller-scale products. Smaller contracts enable new and potentially more flexible procurement options and that can be quicker/easier to run.
On large scale products or services, procurement can require a bigger lift. Timelines and budget are longer and larger, more time can be required up front. BUT — how might we think about procurement in a more agile way?
- How might we weigh the sunk costs of traditional/larger procurement vehicles (staff time/budget) against potential outcomes that don’t meet our needs?
- What’s the risk of a program area becoming dependent on Software as a Service providers to meet evolving government needs, and what if government needs aren’t a priority on that providers’ roadmap?
No big answers here, just lots of musings, especially as we read about the ArriveCAN federal procurement challenges. This is especially top of mind as STB continues to provide ENV product teams procurement support (along with our internal procurement specialists) and work to build internal digital capacity, so we’re less reliant on outside contractors (but also know when it’s beneficial to have outside help!).
Carpenters come to work with tools in their tool belt. A recurring theme for designers (and developers to some extent) in government has been they don’t have the tools they need to do their job. Just as we wouldn’t ask a carpenter to build a house without a hammer or drill, we shouldn’t ask digital service delivery teams to build services without modern tools like Figma (used to design user interfaces), AirTable (a searchable repository for research insights), GitHub (an open space to post development code) and JIRA (an agile product management tool). Yet, as these tools are predominantly Software as a Service (SaaS) tools, they each require privacy, security and legal sign-off and discussions, which take time and money (procurement!!!).
Harry has been working extensively in Figma during his time with STB. It’s what he used to design the initial CleanBC.ca and BCParks.ca interfaces. Now, Harry’s using Figma to build an ENV-specific design system that can be leveraged across the ministry (and hopefully the natural resource sector). A design system is library of common design components (buttons, headers/footers, etc.) that can be shared across multiple teams and reduce the need for custom design and development. This helps government digital services look and operate in a consistent, user-tested way. Harry has also been working across the government design community to support a government design system (which the ENV system would be a child of). This can help teams work more quickly and set a common understanding of governance and systems work. You can go deep on how the Gov.UK Design System accelerates digital delivery, if you’re interested.
I’m really excited for our branch to onboard ENV onto the Figma enterprise license this spring (and shout out to the Ministry of Citizen Services for bringing us onboard!). Harry’s work on design systems and Figma onboarding will help lay the path for other digital teams to quickly pick up the tool and benefit from the efficiency of pulling common design tokens (i.e. buttons, header/footers, etc.) from a central library. A reminder that digital teams need different tools to do their jobs!
Looking ahead, here’s to getting outside more now that the days are longer and the sun’s a bit warmer. Oh! And we’re planning a ministry Agile Open House in April, followed by a month of digital learning in May. More on that to come.
The opinions and views expressed in this post are solely the author’s and do not represent those of the Province of British Columbia or any other parties.
