What you need to know about the discovery process in software development

When we want to build a house, before we start digging the foundations, we should sit down with households and develop a clear and complete understanding of the expectations for the new building and the ways it will support their needs. We do the same when we build the software solutions, calling it the discovery or scoping process.

What is the discovery process?

Looking at software development projects from a high level, we can recognise the Discovery process that tries to answer the question “What do we want to achieve?” and the Delivery process, which answers “How we will get it?”. Therefore, the Discovery process helps the business and delivery team build a clear understanding of the goals for a new software application and how the application will address problems to solve. So, it’s essential to handle the discovery process well as missing well-defined goals, even with perfect technical implementation leads straight to exceeding deadlines and budget.

The discovery process should be tailored to the specific project and environment. Startups and greenfield projects used to rely on assumptions. Agile methodologies address uncertainty by breaking up work into several phases and involve constant learning from results and collaboration with stakeholders. Therefore, the discovery is not only the initial project phase but also an ongoing process.

The initial phase of the discovery process

Stakeholders interviews

In the beginning, we need to identify all goals and expectations about the projects, so it’s time to interview everyone who has an interest and can either affect or be affected by the project. When interviewing, we should not judge or prioritise the needs but try to break up goals and expectations into small, measurable, achievable, relevant and timely items (following the SMART goals criteria). If we work with a vendor, it’s essential to show the big picture of the company and expectations on how new applications will change the business. For vendors, interviews are also an excellent time to understand current stakeholders' roles in the company and how they want to contribute to the project.

Even more important is understanding who will be a user of the system. It’s easier when stakeholders are also the only ones who will use the application, as then, we can ask questions directly. However, often, users who will use the application are the company's customers, and then we need to define their profiles and needs. It will help the delivery team build an application that more precisely address the issues and better supports the project goals. Stakeholders' domain knowledge, previous market research, and competitors' analysis are essential.

Research

Next, it’s time to do homework and refine the collected information. We need to ensure that the shared vision for the application is aligned with all goals and expectations. We also should make up research for missing areas like reviewing similar software, market research, and competitor analysis. Finally, we can prioritise goals and prepare a high-level solution proposal based on that. We don’t need to prepare documentation with hundreds of pages, but at this stage, we find valuable the set of five following documents:

1. Goals statement and value proposition - a refinement list of goals provided by all stakeholders.

2. System requirements - a high-level list of functional and non-functional requirements that support defined goals.

3. Project roadmap - the plan that defines major steps and milestones of the project implementation.

4. Application architecture - map describing the organisation of a software system and interactions with other systems.

5. RAID Analysis - list and plan to mitigate Risk, validate Assumptions, resolve Issues and manage Dependencies.

Optionally, suppose a small project size and few uncertainties. In that case, we prepare application wireframes - a visual guide that represents the skeletal framework of an application and helps understand the project's outcome. Furthermore, if the application is not an internal tool for a company and users of the application are not only stakeholders and employees, we should also summarise collected information about users' personas.

Workshops

Once we have prepared a plan for a project, it’s time to go back to all stakeholders and validate the proposition. Sometimes, the proposed project plan can not meet all expectations right away, but the most important thing is to ensure that all stakeholders understand the priorities and why some topics need to be postponed. Therefore, sometimes we need a few iterations with research and workshops to find an acceptable plan for everyone.

Because the outcome of Research and Workshops is input for the delivery team, the question that often comes up is how much we should go into detail with our requirements and analysis. We should stop on a details level that is still manageable and comfortable for stakeholders and the delivery team to start a project. We will not address all uncertainties, but we need a shared understanding of what they are and how we will manage them in the future.

The ongoing discovery process

The Discovery process does not stop at project kick-off. When a delivery team starts working on the application, they can cooperate with stakeholders, collect their feedback, and go deep into details if needed. We also need to consistently update our RAID analysis and address the issues that came up.

But, once the delivery team releases the first version of our application, things can change quickly. We can take advantage of the iterative approach to software development and start collecting users' feedback from the first version of our application, measure user behaviour, or perform A/B testing. It’s a valuable source of learning that can address assumptions or risks from RAID analysis and adjust our plans to address the project goals better or even exploit new opportunities.

Summary

We should pay attention to the Discovery process for software projects and ensure that stakeholders and delivery teams cooperate. If we are looking for a vendor to build the application, we should consider who and how to support the delivery process and empower cooperation. However, if we do not have competencies in the company, it may be a good idea to find a vendor who can manage the discovery process besides technical skills.