How to run a successful discovery

At Thoughtworks, discovery is one of the most critical phases of a software engineering project, especially in the digital transformation or modernization space. It is when we do the ‘thinking’ part of software development. We consider comprehensive discovery sacrosanct because it helps us set a robust foundation of technological and cultural understanding based on which software is built. It helps us build the context for the problems we’re solving. We typically run an intense discovery for eight weeks — discerning the legacy system in 4-5 weeks, and devising the optimum solution in 3-4 weeks.

In my experience working with global retail clients on projects, I’ve learned a thing or two about conducting successful discovery, which I share in this blog. Some of them might sound rudimentary at the outset. I’ve learned that what sounds simple is, in reality, the most complex thing to practice. Here are also some tips for the practitioner.

Lesson #1: Context is everything

This is a baseline lesson. To be fair, every development team conducts detailed audits to understand the tech landscape. However, there’s a catch. Most often, discovery teams focus only on the tech elements, without properly scrutinizing the organization's cultural fabric, even though this is critical to the functioning of the organization.

In the discovery phase, spend time understanding team structures within the client organization. Ask for all the help you might need from SMEs, program managers, product managers etc. Clearly articulate your own roles and responsibilities within this structure as well, including expectations, boundaries and scope for all parties involved. Be transparent and build great relationships with each stakeholder. Inspire mutual trust and paint a picture of potential transformation. 

In some cases, a stakeholder might believe they are being pulled into unnecessary meetings because they aren’t involved in the assignment so far. A perfect example we see is in data and analytics projects. Typically, in any organization, the analytics teams have ownership of data. At Thoughtworks, we believe that business teams, which need to own their data, understand business context and applicability best. So, we seek to understand more from them, which they might be surprised by. Working with them on why their role is critical can change how they see things and inspire more enthusiasm for the outcome.

Lesson #2: Go in well-prepared

Discovery begins even before the first conversation with the client. To set yourself up for success, start with research and planning. Here are the most important things to be prepared for:

Client context: Understand the client’s business, market segment, current trends, competition, etc., within the context of the problem you’re solving. Also, read a bit about how other organizations are solving similar problems.

Goals and expectations: Before speaking to anyone, set clear objectives for each step. And define expected outcomes. Don’t go into a meeting with an open agenda or expect the client to give you all the information in a structured way. Take charge of getting what you need and structuring it.

Agenda: Five weeks for discerning a legacy system might seem like a long time, but it’ll fly before you can find an open slot in an SME’s calendar! So, build the agenda for the entire 4-5 weeks. Consider:

• The logical workpieces you need to achieve the objectives

• Ways to get these workpieces such as interviews, walkthroughs etc.

Questionnaires: For successful discovery, you need to drive the conversations with the stakeholders. To do this, you need to have a structured set of questions. Get them ready and reviewed well before the meeting. 

Logistics: When you start discovery, you’ll realize that logistics can soon become a nightmare, wasting valuable time. So, get ahead and manage logistics proactively. Block relevant stakeholders’ time, leverage toolkits for collaborative exercises, draft session interview plans, create a kick-off presentation and find innovative ways to keep going.

Lesson #3: Have a plan. Share the plan.

Your plan is only as good as your stakeholders’ knowledge and understanding of it. So, once you make a plan, gain your stakeholders’ confidence by sharing it with them ahead of time. Define high-level timelines explicitly and brief all stakeholders about the program outline like below.

Lesson #4: Be agile and demonstrate it

From your initial discussions with the stakeholders, you’ll have a sense of the client’s ecosystem, promoters, detractors, etc. Adapt your approach accordingly.

• Contemplate how you’ll navigate organizational politics (to be expected, right!)

• Create a stakeholder map, perhaps a Responsible, Accountable, Consulted, Informed (RACI) matrix, to identify who will give sign-offs, who will share information etc.

• Conduct working sessions — a collaborative and live whiteboarding/mind mapping exercise — if interviews are not getting you the information you need

Lesson #5: Avoid surprises

No one likes a nasty surprise. Imagine reaching the end of eight weeks and realizing you had it wrong all along! To prevent that:

Validate your understanding persistently. Play back the information you’ve collected and check if that’s right. Present the challenges with evidence and confirm agreement. Point out patterns from data, if any.

Involve sponsors/ primary stakeholders right from the start. Have regular check-ins, take them through your progress and gather feedback. 

Align concerned teams to your final solution recommendations.

Lesson #6: Close out on a high note

At the end of eight weeks, the client needs to see value in our work. This entirely depends on how you demonstrate it in your final report. So, work on it like you are creating your own brand. 

• Summarize the goals

• Show how you’ve achieved those goals

• Present all the possible solutions and how you’ve prioritized them

• Make clear and actionable recommendations

• Envision the future journey through inception and delivery

Make sure to make this impactful. Take a visual designer’s help if required.

Bonus lesson: Don’t confuse discovery and inception

Often, teams try to blend discovery and inception to save time. This can be a huge mistake. Discovery is about identifying problems/opportunities to align business goals with a product roadmap. Inception is about planning the solution delivery and implementation strategy. In our software development process, this is how it features.

By combining the two, you might miss out on critical knowledge, jumping the gun on solutioning. It’s best to avoid that for more sustainable success. For more on inception, read this article by Paulo Caroli, an Expert Inception Facilitator at Thoughtworks.