Discovery of a project: key aspects

01 Sep 2022

Before starting a project, there are many variables to consider in order to know whether the efforts we are about to undertake make sense, both for us and for the intended users. It is like trying to go into battle without a plan, we have to set a roadmap to guide us, but not before we know what we have, what we need and whether all those involved are aligned to the same goal. Lesmes López, Agile Delivery Manager (ADM) at Codurance, led a meetup in which he offered keys, useful tools and guidelines to successfully carry out the discovery of a project.

He started with the essential: What is the discovery of a project?

Activities and deliverables that allow us to understand and align on a problem and the most appropriate solutions with the available means.

- Lesmes López, Agile Delivery Manager

From this definition, he explained the importance of each of the elements of a discovery.

Activities and deliverables

They are the output of a discovery, in other words, the representation of the activities obtained from our discovery. There are many formats that can help us to represent these activities and deliverables, we must choose the one that best suits our project.blog_discovery_2_en

Understand and align

If each team member does not share a common vision of the problem or does not understand the available information in the same way, it is very likely that the solutions they come up with will be very different from each other or will focus on different aspects. Therefore, the outcome of a discovery is that the activities and deliverables allow us to understand and align as a team towards the same objectives. As López says: "The important thing is that we come out with a joint and aligned understanding of the needs we need to meet".  

To this end, it is advisable to analyze the problem from different perspectives. The ADM points out three angles to be considered:

  • Business (value) - What value is provided to the user.

  • UX (user) - What is the user experience and how can it be improved.

  • Technology (feasible) - How feasible it is to implement, maintain and improve over time the solution we propose.

In seeking this alignment, it is important to involve stakeholders, who are ultimately the people who will help understand the problem and the possible solutions available. Among them, he highlighted the domain experts, the sales team, technical leaders, the marketing team and, above all, the detractors. We should not leave out the people we know can complicate a discovery. "It is key to incorporate the detractors from the beginning, because sooner or later you will find them and they can generate blocks to certain solutions," he said. Ultimately, it's about creating a common vision from each particular perspective. 

blog_discovery_3_en

Problems and solutions

So, what do we want to align on? On the problem that blocks us or does not allow us to move forward and the solutions to respond to that problem. This is the key. López explained that in order to address this shared definition of problems and solutions, several levels must be taken into account, since depending on the degree of uncertainty or complexity in these areas, more emphasis will have to be placed on some tools or others. The nature of the problem to be solved defines the activities and deliverables. For example, if the project we are going to address is more tactical than strategic, the tools we use will be focused on reinforcing the tactics since we assume that the strategy already exists. We may reinforce that strategy a bit at the beginning, but in the end we will focus on the tactics.

Likewise, the discovery can be to create a new product, to develop new capabilities of an existing product, which is most common when developing software, or to implement a modernization, for example of a legacy system. Depending on the main need, the solutions will be aimed at solving the detected problem. The discovery has to do with the amount of information that we do not know and have to discover.

According to these categories, López presented some useful tools for each case:

      • New product
        - Business Model Canvas. It's a tool that makes it possible to shape a value proposition. Realistic hypotheses must be formulated.
        - Steve Blank, Customer Development. Focus on the customer. We are not going to develop a product but a customer, we have to understand what they want.

      • Modernization of a legacy system
        - Value Stream Mapping.It shows the value generation process and identifies where queues or bottlenecks are generated. It helps to find the points where time can be saved in order to optimise the value stream.
        - Architecture Discovery. Shows what the current architecture is like vs. what it could be like.
        - Event Storming. Mapping a product to understand the critical areas that need to be addressed to make the whole system work better.
        - Service Blueprint. Mapping what the service looks like to visualise it and make decisions based on that. 

      • Useful in any case
        - Gathering of expectations, realistic or not. 
        - Wardley Maps. Strategic analysis tool that makes it possible to visualise where the project should evolve in order to provide more value.
        - Customer Journeys. Detailing the user journey to establish the pain points that can be resolved in order to improve the experience.
        -Interviews with users.
        - Shadowing Session. Sessions that allow us to observe what users do and evaluate it in order to know which points can be improved.
        - Design Sprints. A series of hypotheses and tests that help to establish the problem and the solution.

Neil Killick explains three areas that help us understand the division between the problem space and the solution space. First there is the capability, which is exactly what the user needs to do. Then there is the functional area, which describes the tools we need to implement so that the user can achieve what they are looking for. And finally, the technical area, which is the steps we need to take to implement the functionality the user needs.

Blog_discovery_4_en

Appropriate with the available means

This is the basic point, the discovery must be realistic in terms of the means available. To do this, it is necessary to take into account the nature of the team we have (innovation lab vs. product team) and the type of company we are in. Solutions must fit the context and the environment in which we are operating.

To illustrate this section, the ADM introduced the iron triangle adapted from Kent Beck in which, playing with the variables of scope (more), cost (cheaper), time (faster) and quality (better), he describes 3 different stages within developments

  • Explore (better/sooner/cheaper) - Limit the scope but speed up the feedback. Do as much testing as possible, the aim is to deliver quickly and collect that feedback.
     
  • Expand (better/sooner/more) - Delivering fast and high quality functionalities, but without limiting the cost. 

  • Extract (better/cheaper/more) - Getting the most out of the product. Cost-effective delivery of long-term, large-scale value.


These stages show three moments in which a product can be in, so the discovery of the project must be adapted to the stage in which it is: explore, expand or extract. Bearing in mind that quality (better) must be intrinsic in any of the stages.

blog_discovery_1_en

Inception Deck

To give an example of actions that can be taken when setting up a discovery, López introduced the Inception Deck. This is a set of dynamics that allow the collection of information to establish purposes and objectives, and in which the whole team must participate equally. It consists of 10 steps:

1. Why are we here? - Compilation of objectives. Find a single, clear and measurable objective for the whole team. 

2. Elevator pitch -roduct definition. List qualities of the project so that everyone has a clear definition of what it is. Who it is aimed at, competition, unique characteristics, etc.

3. Product box - List the key points of the project. How would you sell it?

4. Not list - A list of what does not fall within the project to limit a scope. Helps to streamline communications.

5. Meet the neighbors - Identify the map of all the people who influence the project. Consider all those who may be affected by or have an impact on the project.

6. Show solution - A high-level approach to what the solution would be. It does not have to be the final product, but a first approximation. 

7. Up at night - Make an analysis of the possible risks that may affect the project. Be clear about how likely they are to occur and how serious they are.

8. Size it up - Estimate the magnitude of the project and the time it would take to implement it. *Lopez does not emphasise this step because he considers it to be of little value. 

9. What' going to give - Establish which qualities or characteristics are indispensable and set the direction and decisions on the solution in a certain way. Our 'trade offs'.

10. What going to take - Estimate the cost of the project and the decisions involved in this commitment. *Lopez does not emphasise this step because he considers that it doesn't make a major contribution. 

Other tools that he mentioned as being of great importance and useful within a discovery are the User Persona and User Story Mapping. These allow us to define the profile of our end user, the path they follow with the product and in which areas we can offer a better experience.

This meeting was part of the Agile Project Management circuit that aims to offer useful resources to work with agile projects effectively. If you are interested in reviewing more content on this track you can do so on our Insights page where you will also find videos of past sessions and podcasts. Also, if you want us to send you relevant content to inspire you, subscribe to our newsletter. 

Bibliography: