Ruminations after 5 months with the BC digital investment office
I joined the Digital Investment Office in the BC Public Service five months ago. While that’s a relatively short period of time, I’ve been able to learn a lot about the nuances of digital funding in government.
This is a great realization, as I refer back to a story I wrote in 2020 when working for the Federal government. At that time, I wrote
The piece that’s the most foreign to me is the funding piece. We have project-based funding right now. Shifting that to dedicated product funding seems like a significant departure. And does it even really align with those top-down mandates? This is about how to structure a technology group, not how to deliver a safe and efficient transportation system for Canadians.
— The Government of Canada is not a software company | by Andrea F Hill | Medium
Now that I am firmly seated in a team that reviews IM/IT capital funding requests, I have a slightly better understanding.
These are my top reflections so far..
1. The word “service” does us no favours
We talk about service design, connected services, service delivery. The word “service” is all over what government does, and of course we should be trying to improve how we deliver services to people.
It gets tricky when we start looking for capital funding to do so. Capital funding “covers expenses related to the creation of an asset that provides future value to the B.C. government”. When reviewing IM/IT capital cases, we spend a lot of time asking “but what are you building/buying”?
But honestly, building a new thing (or enhancing an existing thing) doesn’t always have the improvement we expect it will. Building stuff is actually not the hard part. Building stuff that’s an improvement over the incumbent solution, that enables people to do things faster, cheaper and with fewer errors is actually a bit trickier.
Rather than focusing on the solution (what is the thing you will produce), we ideally should be focusing on the outcome — for much of what the govt does, that’s going to be “improved service delivery”.
Unfortunately, accounting/finance really likes to focus on those assets, though. What is the thing that was produced, that will provide future value.
This is kinda a mismatch of how government departments are increasingly being structured and measured. They are orienting around service lines, and trying to deliver on end-to-end services that match the user journey, but funding is still focused on these discrete assets along the way.
2. You can’t know how much something is going to cost without discovery
This isn’t something I’ve recently learned, but it is a bit of a gotcha when it comes to digital funding.
If you’re going to make a request for capital, you have to say what you’re going to build/buy. How do you know?
With the exception of working on legacy systems with complicated business logic (and to be fair, this is a LOT of govt IT projects), building something isn’t actually the hard part. The hard part is figuring out WHAT to build.
Actually, I take back that previous statement. Especially including old legacy systems with complicated business logic.. You have no idea what you’re going to find til you open the hood. So how can you make a reasonable estimate of how much/how long its going to take to fix it?
You need to do some discovery. Could be with end-users, could be about process, or technical investigation. But before you ask for funds, you should have some idea of what you’ll be doing with the funds.
Seems straightforward. But here’s the gotcha: you can’t do that discovery and planning with capital funds. Capital funds are to go towards *building* things.
Even if the thing isn’t really the best way to address a problem? Yeah, sure.
Even if the thing has to be refactored and subject to a long testing period prior to launch because things were developed before they were really designed? Yup.
Unfortunately the system rewards DOING, not DOING THE RIGHT THING if the right thing takes some intentional research and planning beforehand.
Ironically, a team can also get dinged if they get partway down the doing path, and decide to write off the asset (not launch).
So we have a system that doesn’t incentivize research and planning, but then also penalizes you if you ‘guess wrong’ while you’re building.
I do think the tide is turning, where organizations are seeing the importance in understanding a problem/situation before rushing to a solution. Even if they need to use operating funds to do so.
Which really should be fine, because honestly..
3. Using capital is just deferring the cost
When teams submit business cases to us, they need to submit a financial workbook that also demonstrates they are aware they will need to sustain the asset, and also cover amortization out of operating funds.
Although I don’t entirely agree that the cost of building the thing = its value for amortization purposes, that’s how it is.
So you can request capital funding to build something, but eventually you are going to have to pay the piper and cover the amortization of the cost of that asset.
Sometimes it seems as though teams think that capital is ‘extra’ money for them to build something. It’s not.. its just some upfront funds, that accountants will account for ;-) over a longer period of time (in our case, 5 years after the product is launched). So when we hear hesitations over not having the operating funds to fund user research/discovery activities, I wonder if they realize that even if they were able to fund these activities this year with capital, they will have to cover it down the road.
Ok, for the next I’m going to switch gears a bit..
4. AGILE DOES NOT MEAN “WE DONT KNOW WHAT WE WILL BUILD”
Sorry, I really had to caps-lock that one.
Unfortunately, the “agile means being responsive and flexible” has become code for ‘fund this group of people, trust us, we’ll figure out something to build, it’ll be worth it’.
This drives me bonkers, because I spent a decade in software companies that followed agile software practices, and it wasn’t a free-for-all. The idea that if we want to fund agile teams we need to empower them by giving them a blank cheque is .. not helping agile win over any cynics.
We had strategic themes and functionality we needed to work on. Did we know precisely how to execute? No, but we knew at a high level what was critical to deliver to meet our users’ needs.
You need to know what problem you’re going to solve, and have some idea on how you are going to evaluate ways to solve it. You should be releasing incremental value throughout, and ideally you should be able to stop at any time and not have a ton of waste.
This one gets a bit fuzzy because ideally an agile team is doing research throughout the process — that’s where a lot of the ‘learning’ comes from. But often people think that ‘doing agile development’ just means following some rituals: daily standups, maybe a backlog to work off of. Nah, it’s actually supposed to be about tight cycles to release and get feedback from users to try to avoid going off in the wrong direction.
You do need strong product leadership, to ensure that you are staying true to your product vision and not just becoming order-takers. It’s a balance, and its a skill. And I do worry when people think they can read a couple blog posts and become experts in leading an agile team.
5. There is not enough focus on (continuous) delivery
As a piggy-back on that last bullet, I’ve realized that I don’t really know how things go after the product launches. On the surface, that makes sense: our funding is about building an asset, and things shift once it is launched.
Except, at my core, I’m a product person. I do actually care about not just ‘releasing something’ but ‘releasing something that creates value/benefit for users’. I spent a lot of time worrying about things like user onboarding, and change management, and support (I worked on UbiMeet right when Intercom hit the scene with its customer support chat tools.. I remember actually getting excited when a user reached out with a question!)
I.. dont know how that works with the assets we fund. I mean, those are all things that should be handled as part of operations, but often when we’re talking about migrating to a new digital tool, it’s people involved with the design and development of the tool that assist with some of that. In the private sector, we considered it “product marketing” and admittedly it had clearer value in a competitive environment where consumers had choices between tools. But still, if we want people to be successful using our tools, we should really try to help them gain competence and confidence using them.
What is the plan to migrate to the new tool? Will the product get sunsetted? How will users be notified and helped with the change?
I won’t name names, but there are many examples where an agency is maintaining several generations of a system because its easier than making someone mad and forcing them to move. What is the cost to maintaining two systems?
Wow, that was quite a tangent from my initial point. Back to it.
If the point of agile is to “incrementally release value”, we should be releasing. All your perfect agile practices mean nothing until people are using what you built.
Let me say that again.
All your perfect agile practices are worth nothing until people are using what you built.
And if you need to work for years on a complete system before releasing anything of value, you’re not really doing agile software development. So let’s hope you got it right the first time!
I know that when we are talking about critical systems, we don’t want to be too fast and loose with product releases. I’m not asking for Amazon- or Facebook-frequency code pushes. We don’t want to overwhelm people with having to learn new ways to work with our products every time they log on.
BUT we do need to shift the idea away from “the first time people see it, the asset is created, the project is done”. We can’t afford to just one-and-done everything. This leads to risk aversion — we want to shove everyting into the release, and try to make it perfect. Instead, we need to figure out a way to account for a post-release cycle, that lets us do some bug fixes and improvements (that don’t materially change the asset) and really lets us learn and refine the asset to ensure it is of the value we anticipated.
I have NO idea how the funding for that would work. Guess I better stick around a bit longer. ;-)
