2. Discovery research and problem statement
Read this regardless of your procurement approach.
Goals
- To bring key stakeholders into the procurement process and draw on their expertise.
- To manage expectations and get buy-in with internal stakeholders.
- To understand users, their jobs, and their challenges.
- To define the (actual) problem and state it clearly.
- To set goals and key performance indicators for the project.
Actions
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.
- Try the following:
- 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
Creating user profiles
Software design and procurement should always be in service of actual users. For that reason, the 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 describe operational procedures as well as subjective experience. Think of them as a “day in the life” or “ride-along” description of real people.
- Embed with the end user (for example, 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 end users.
- Write user journeys that describe the current job and workflow of end users. Write down their pain points and goals.
- You may choose to create personas for each user group. These are fictional, but highly detailed descriptions of different prototypical users who interact with the software.
Writing a problem statement
Arguably the most important feature of a procurement process is the problem statement. This is a short written document that accurately reflects the discovery research you’ve done, and describes a clear, meaningful problem. The problem statement will be the thread that runs throughout the entire process, and will inform all subsequent steps. In short, software procurement and development are both impossible without a clear definition of the problem.
- 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. Agree on a clear, meaningful problem.
- Write out a problem statement. It should be concise and written in clear language.
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 as Key Performance Indicators, KPIs, or outcome-based targets). Procurement is an opportunity to evaluate how you work today, how you could work more effectively in the future, and how to align with broad municipal priorities like climate change or social equity.
- Write out KPIs or outcome-based targets that show the need has been filled or the problem has been solved.
- Write down the broader departmental goals as they relate to the problem.
- Write down broader administration goals, commitments and objectives (e.g. climate change targets, social equity commitments, local economic development, returning citizens…) as they relate to the problem.
Underwriting the problem statement
The problem statement and KPIs will carry forward the entire process. Everyone involved will refer to them, and they are the yardsticks you will use to measure success. All associated stakeholders must have reviewed the problem statement and KPIs 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.
- Collect the research, user journeys, problem statement, and KPIs into a single document, then underwrite it – have stakeholders literally sign the document.
Common challenges
Focusing on existing products
Early stages of the process should adequately define the problem you need to solve. Jumping to solutions may lead to buying something you don’t need, or limit the possibility of innovative, better-than-expected solutions in the long run.
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.
Checklist
- Problem statement based on end users
- Detailed KPIs and broad objectives for the project
- Documentation of the research
References
CityMart Procurement Institute: Defining needs and setting intention
CityMart Procurement Institute: Evaluation framework for problem ideas
Evaluation framework for problem ideas
Discovery Research methods