R00 OXD Pre Discovery Insight Assets Hero V02 ST

Pre-Discovery and the challenge of the fuzzy front-end of digital transformation

“Pre-Discovery” in government may do more harm than good, blending good intentions with vague goals. What’s the aim—funding, defining issues, consensus? VP and Partner of OXD, Gordon Ross, explains that there are better ways to avoid early confusion with your Digital Transformation project.
Share
XFacebookLinkedInEmailCopy Link

Our government digital transformation work brings us into contact with a wide range of teams in government.

Some teams have secured funding, gone out to market, issued a Request For Proposal (RFP), and hired OXD. Some are working on a nascent policy problem and contemplating how digital ways of working can help. Others are responding to a strong policy mandate from an elected official where digital is the desired solution. Some have funding, others do not. Some have a dedicated team, others have a handful of available resources. Some have a vision, others are not yet clear on the problem to be solved. 

One thing we've noticed is a specific tendency among early-stage teams. They often engage in a phase called "Pre-Discovery.”

I’m going to be blunt: we aren’t big fans of this term. And we’re not the only ones who have taken issue with the term Pre-Discovery over the years. 

The Brits expressed their dissatisfaction with this expression back in 2020 and even earlier in 2017. Closer to home, CDS showed how they renamed Pre-Discovery through a practice-what-you-preach design research approach in 2022. And yet, Pre-Discovery is still enshrined in some digital service guidance and toolkits, like the Australian New South Wales digital delivery manual

So, what are teams trying to achieve during the fuzzy front-end of a digital transformation initiative, often referred to as Pre-Discovery? And what’s wrong with Pre-Discovery anyhow? 

Alignment

Over a decade ago, as the UK Government Digital Service's Discovery, Alpha, Beta, Live framework became globally recognized for digital service delivery, BC was creating its Service Design Playbook. This playbook emerged in 2013-2014, led by the Strategic Design and Transformation Branch (SDTB) within Government Communications and Public Engagement (GCPE). It introduced an "Alignment” phase as a body of work to ensure “proper approvals, budget, expectations, and teams are established.” 

The Playbook states:

“Some of the greatest risks to any project include: 

  • Having a misunderstood approach, 
  • Mismatched expectations, 
  • Poor communications, 
  • Lack of commitment, funds, or approvals, 
  • No plan for managing change, 
  • Having the wrong people on the team or at the table. 

It’s important to the success of the project to line up these elements before starting a service design project.”

My interpretation of Alignment was that it assessed partner readiness. As a vendor supporting SDTB, I watched as SDTB aimed to align with the potential client—the line-Ministry that had approached SDTB for service design assistance. While not explicitly stated in the Playbook, I believe SDTB used the process for vetting clients and projects. It assessed if a Ministry's needs justified SDTB's investment of time and effort. After all, SDTB had limited resources and couldn't meet all of the government's demand for service design.

If this process proved successful, both parties would sign a Partnership Agreement. The agreement outlined how they would meet their shared responsibilities. It included business objectives, project background, work breakdown, and Ministry responsibilities. It also covered assumptions, dependencies, schedule, and budget.

Wrapping up Alignment successfully would lead into…. you guessed it…. Discovery. This made Alignment a valid and logical Pre-Discovery phase to be sure. 

Alignment forced teams to get their ducks in a row. Which worked well for teams with ducks. 

But what about those without them? Without funding, without a clear sense of the problem, without a team, or with low consensus or competing opinions about “solutions”?

Exploration

Like the GDS and CDS before us, we agree that “Exploration” is a more meaningful title to afford a wide range of activities focused on research, readiness, funding, and governance that needs to occur prior to team formation and more formal funding and project inception activities occur.

While the context of our work brings us into contact with digital teams solving problems using digital tools and ways of working, there are many possible courses of action for government to address the public and its problems. And unlike the logic that Discovery follows Pre-Discovery, the result of Exploration can be varied.

During the fuzziest of front ends of initiatives, teams and informally arranged groups who share a common concern can benefit from a broad look at the architecture of the problem. This creates a better understanding to yield options like turning off existing services, stopping doing things, or changing how departments work together. The default answer need not always be “design and build a digital thing.” 

Exploration can use its energy to condense a foggy, difficult-to-grasp problem into something more tangible and legible. The result of this condensation is “problem as liquid”—still tricky to handle, but contained in a much better way than before.

Exploration can also be used as a speed bump. Like a traffic-calmed go-slow zone, it can absorb the energy of a prematurely defined solution, one that may appear attractive or convenient, yet without evidence of its efficacy. Exploration in this mode, like a rigorous Discovery phase that may follow, is a cheap insurance policy that avoids spending lots of money on a questionable idea.  

In this version of Exploration, the sharp and pointy solution from on-high, like an icicle falling towards the team at a high rate of speed, can be heated up and melted through some well-applied research friction. Exploration again results in “problem as liquid”, hopefully reducing organizational harm along the way. 

Some of the following attributes have stuck out to me in reflecting on this interstitial moment where projects aren’t yet projects, teams are mid-formation, and problems are still contested. 

Consider how much or how little you have sorted out:

  • nature of the problem (a spectrum of fuzzy/unknown to sharp/clear)
  • coherence of the evidence (related to the problem; low/high)
  • degree to which a solution has been predetermined (low/high)
  • consensus that "digital" or "technology" is the solution (spectrum of low/high agreement)
  • team composition and alignment to the problem (team exists, roles described/no team, no structure)
  • work to be done (what approach makes sense, what activities to undertake/no sense of how to proceed)
  • funding (who's paying for this work to be done and how/no budget, no known sources)
  • governance (what decision making structures does the work relate to, what new ones may need to exist)
  • partnerships (where the work lives within a broader organizational context, who else is involved or impacted?)
  • timing (related to the sequencing of funding/governance/team formation, what comes first, etc.)

And I’m sure there’s lots more. If you’re having a hard time coming up with answers for those questions or only have a handful of them sorted out, then good chance some Exploration could help. 

Here’s some sample Exploration activities that can help tackle your biggest or most nebulous challenges at the fuzzy front end:

Here’s some sample Exploration activities that can help tackle your biggest or most nebulous challenges at the fuzzy front end: user research into the service problem (interviews, fieldwork, sensemaking) desk research into the broader problem context (government data sets, academic literature reviews, previous research reports) rough sketching or storyboarding of predetermined solutions to make them legible comparative research into other jurisdictions use of digital technology to solve similar problems and subsequent myth-busting if required team design prototypes (using team topologies or other sound team design principles) value chain mapping to understand capabilities associated with user needs meetings with IT portfolio managers on funding paths (within ministry or centrally located funders) stakeholder mapping / governance scanning to understand decision-making structures

If you do have some or most of those things sorted out, congratulations, you’re on your way! In BC, there’s lots of good guidance and resources on the path to follow towards digital service funding, teaming, principles, and delivery methods that now exist. 

Fuzzy front-end challenges?

We’re curious to know if you have had the space to do Exploration at the start of your journey or how you’ve tackled the fuzzy front-end of digital transformation.