Crafting a Collaborative Approach to Digital Oversight

As I prepare to close this chapter on my role in digital investment, I wanted to capture and organize some thoughts. Over the past two years in the BC government, I’ve been deep into the world of IT project financing — and it’s been a steep learning curve. Seeing firsthand the structural hurdles digital teams face, even in a jurisdiction well-equipped for digital service delivery, has been eye-opening. Along the way, I tackled one of those hurdles: the digital funding process, and I’d like to think we made some real progress.

My first role here was as a Digital Analyst, reviewing IT funding requests and advising decision-makers. But soon, I found myself wrestling with a bigger issue: oversight. How do we catch projects that are veering off course — heading for budget overruns, delays, or worse — and what can we do about it? I was introduced to this challenge somewhat by chance. A service design project needed an extra hand, so I jumped in. It turned out to be one of the most rewarding digital transformation projects I’ve worked on.

Before I dive into that, here’s some quick context on the BC government’s digital environment. BC is well-structured for digital delivery in many ways. Digital project delivery is mostly decentralized in Ministries, with relatively little red tape from the center. Capital funding for IT, however, is an exception — it’s scale funding. A Deputy Minister Committee on Digital and Data makes funding decisions at the project level, and sets the overall strategy (BC’s Digital Plan). The Digital Investment Office (DIO) supports the DM committee by analyzing funding requests, providing secretarial support, and the digital policy team resides here too. The DIO operates under the Chief Digital Officer within the Office of the Chief Information Officer. BC’s digital principles are embedded in core policy, and the funding criteria for IT projects align with the principles. Everything is integrated and connected…in theory. In practice, the experience of project teams trying to secure capital funding needed improvement.

Historically, once projects were funded, teams submitted quarterly status reports to the DIO. But our user research showed that these reports weren’t doing their job: they were time-consuming for teams, lacking nuance, and left us without a real sense of project health. Instead of building trust, the process created frustration.

The service design project focused on rethinking the DIO’s processes to address two major issues. First, the confusing, frustrating experience for ministry teams seeking funding. Second, the lack of tools and information the Deputy Minister Committee needed to assess investment risk and support projects in trouble. As we dug deeper, we also saw that accountability for IT project outcomes was diffuse over various roles. We needed a single point of accountability — similar to the UK’s approach with the Senior Responsible Owner role.

To find solutions, we looked at how other governments handle governance and oversight. Our goal was a light-touch approach that balanced oversight with autonomy for delivery teams and didn’t add unnecessary bureaucracy. We wanted a collaborative model that fostered relationships. Ontario’s Digital First Assessments (DFA), developed by the Ontario Digital Service (RIP), were inspiring. DFA used stage-based assessments to evaluate teams against Digital Service Standards, leading to go/no-go decisions. We borrowed some assessment materials, but with our limited resources, fully adopting DFA wasn’t feasible.

We also spoke to the Australian Digital Transformation Agency about their Assurance Framework for Digital and ICT Investments, which became the basis for our approach. Australia has done some amazing work to organize effectively to bring digital services to life.

In the end, our adapted framework rested on these pillars:

1. A program area Responsible Executive Director, accountable for project outcomes.
2. Investment decisions based on key outcomes, and progress towards these measured by clear success metrics and key performance indicators.
3. Risk-Based Tiers for projects, with tailored assurance activities for each.
4. Initial Briefings shortly after funding to build rapport among program, IT, and investment teams, and to discuss the project’s assurance plan and KPIs.
5. Project Health Checks for higher-risk projects — these are lightweight status meetings focused on investment health.
6. Escalation Protocols for projects with persistent, unresolved issues that threaten delivery.

The Project Health Checks might just be the key ingredient our secret sauce. On the investment side, we need confidence that the team can complete the project successfully and that funds are well-spent. Project teams, on the other hand, want resources and empowerment to get the work done and communicate progress without heavy administrative overhead. The project health checks are the leanest structure we could devise to meet these needs. These informal check-ins have just three agenda items:

1. Progress Review: What capabilities/work is complete? What are you learning?
2. Financial Review: How much have you spent?
3. Roadmap Review: What’s next?

Project health checks do more than just keep things simple — they bring people together. One of the biggest relationship challenges we recognized was the power imbalance between oversight bodies and project teams. We also saw that some program leaders were new to managing IT projects and partnering with IT. We hypothesized that stronger collaboration between program areas, IT, and the DIO would help BC operate as a modern digital service organization. We also hypothesized that fostering psychological safety would create the conditions for change. These ideas became the core design principles for project health checks. Although these checks are still relatively new, the feedback we have received has been very positive.

Lastly, we took a hard look at the value proposition of building a stronger central support for digital delivery — a question our users raised frequently, and one we welcomed. After all, we were asking project teams for a lot of information and vulnerability without giving much in return. So what’s our value add? First, regular check-ins with project teams could actually streamline future investment requests. With a clearer sense of each team’s progress and challenges, we could make faster, more informed decisions. Plus, being part of the OCIO put us in a unique position to connect teams with resources and help them get unblocked.

Assurance itself has real value, too. As a third party, we can ask the kinds of questions that help project teams step back, see things differently, and align more closely with best practices like the Digital Code of Practice. Just as an athlete benefits from a strong core, so does a decentralized delivery environment from a strong center — it provides essential support to those on the ground doing the work.

It’s early days, but we’re excited to track our progress and keep strengthening this foundation.