Process code for software procurement

1c. Discovery research

This section will help you:


Bring stakeholders into the process and draw on their expertise


Manage expectations and get buy-in


Understand users, their jobs, and their challenges


Define the actual problem and state it clearly


Set goals and key performance indicators for the project

Common challenges

You may encounter these frictions as you do the work of discovery research. These are challenges the Recommended actions are designed to solve, or that may arise as you take those actions.

Focusing on existing products

It’s common to have existing products in mind as you start a software sourcing process. However, jumping to existing solutions without defining the actual needs can lead to buying something you don’t need, or limit the possibility of innovative, better-than-expected solutions in the long run.

Lack of creative confidence

There is a myth that civil servants aren’t, or can’t be, creative and can’t design software. This is false! You are the person who is best suited to understand the problem and imagine solutions. A good development partner will integrate your design input.


Insufficient or ineffective user research

Not addressing the end user can result in building something that is incompatible with the day to day nuances of their job.


Lack of resources for discovery research

Not having adequate time, resources or knowledge for a discovery research phase undermines the entire procurement and development process. Allocating sufficient time and budget for initial discovery work will save money and frustration in the long run.

Recommended actions
1. Doing discovery research

Discovery research is a way of getting close to the problem at hand. Many different methods can be used, but the overarching goal is to understand the technical, social, procedural, and subjective dimensions of the problem you are trying to solve or the process you are trying to improve—with an emphasis on the end user.

Union Group 194 Line 48

The following design research tools are useful ways of understanding users:

Cognitive walkthrough
Contextual inquiry
Workshops with key stakeholders
Stakeholder and user interviews

Dot voting
Five whys
Heuristic evaluation
Mapping out opportunities, challenges, ideas and fears


Use discovery research tools and methods

Engage with various different groups of stakeholders to ask questions, surface ideas, and prioritize them.

2. Creating user profiles

Software should always be in service of its actual users. For that reason, the procurement process begins with mapping out who those users are, understanding their roles, understanding their expertise, and documenting the risks and challenges they face. User profiles (also known as “personas”) describe operational procedures as well as subjective experiences. Think of these user profiles as a description of a real person and a day in their life at work. Of course, your write-ups should be anonymous, incorporating elements from several different end users.


Embed with the end users

Accompany a municipal service delivery department employee and document specific requirements of the tasks they perform.


Consider other users who are involved

This may include superiors, auditors, people who read regular reports, or people in other departments whose work interacts with the user you are focusing on. Begin to create additional user groups as needed.


Create personas for each user group

These are fictional but highly detailed descriptions of prototypical users who interact with the software. They should incorporate insights from several different real people.

Write user journeys

Describe the current job of the end user. Write down their workflow, pain points and goals. Repeat for individuals in each user group. Here is an example—use this as a template, or create your own.

College degree, Mathematics
Tulsa, Oklahoma
Greta Hansen, 27
Transit Data Analyst
Meet delay reduction KPIs
Learning to code with React
Gaps in service delivery
Public perception of transit efficiency
Changing political priorities
User story
Greta is an early-career transit data analyst who was recently hired by the Tulsa metropolitan transit authority. Her job is to use existing data sources—and identify new ones—that help to predict and reduce delays in public transit services. To do this, she is building a workflow on top of the transit authority’s existing API.

3. Writing a problem statement

Successful software procurement requires a clear definition of the problem you aim to solve. This short written document details the problem and accurately reflects your discovery research. Put careful thought into the problem statement – it will be the thread that runs throughout the entire software sourcing process.

Consider your user research

Identify a number of problem(s) that need to be solved. Meet with associated stakeholders and collaboratively prioritize problems. Keep looking for multiple problems that are complementary—problems that have similar causes, even if they look different.


Write out a problem statement

Agree on a clear, meaningful problem that needs to be solved (and be open to the possibility of solving it without software!). The problem statement should be concise and written in clear language.

4. Defining Key Performance Indicators (KPIs) and broader goals

The problem statement should be accompanied by specific metrics, milestones or observable improvements that indicate the problem has been solved (often known as Key Performance Indicators, KPIs, or outcome-based targets).


Write down broad administration goals, commitments and objectives

As they relate to the problem, include things like climate change targets, social equity commitments, local economic development, returning citizens.


Write down the broader departmental goals

As they relate to the problem.

Write out your KPIs

Review the problem statement and consider how you might measure the success of a solution. Also think about how a solution could advance departmental or administration-wide objectives. KPIs can include both.

5. Underwriting the problem statement

Everyone involved will refer to this and the KPIs throughout the procurement process. These will guide your work, empowering you to design a successful solution. All associated stakeholders must have reviewed these before moving forward. Early buy-in and aligned expectations will reduce risk and save significant time over the course of the procurement or design process.


Get stakeholders to sign a unified document

Collect the research, user journeys, problem statement, and KPIs into a single document, then “underwrite” it—have stakeholders literally sign the document.


Software may not be the best or only solution

It’s easy to assume that new software will solve all of the complex problems you and your colleagues are facing. But sometimes software is not the only or best solution. Once you’ve written a problem statement, KPIs and goals, take some time to explore many and varied ways of approaching the problem and achieving your goals without software. Consider:
Changes to bureaucratic processes, budgeting, or policy directives.
Communications and shifting departmental norms.
Partnerships with outside organizations.

Create or complete the following outputs before moving on to the next step.

gear 2 arrow 2
Documentation of discovery research
gear 2 arrow 2

User profiles and user journeys

gear 2 arrow 2
Problem statement
gear 2 arrow 2

Broad goals and detailed KPIs for the project

Further reading
The Atlas

A toolkit to help government officials to develop a clear problem statement and select the most appropriate procurement approach for the issue they want to solve.