![icon.goal](img/icon-goal-15@2x.png)
Bring stakeholders into the process and draw on their expertise
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Create or complete the following outputs before moving on to the next step.
User profiles and user journeys
Broad goals and detailed KPIs for the project
Defining needs and setting intention
Free Procurement Toolkit For Cities
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.
Understand and define users with the User Profile Model