How not to f*ck up the project discovery phase

For many of us, the project discovery phase could be represented by the phrase, “come on, let’s start the work. Why waste time?” People give you money and tell you to build a rocket, but where will this rocket fly, and do we really need that rocket? It’s better to learn about that during the discovery phase of projects.

My name is Olena Goncharenko, and I’m a Senior Service Delivery Lead at Brightgrove currently working on the Ada Health project. Today, I want to talk about the importance of the discovery phase of a project and how to do it to get your project on the right track. This way, you won’t need to rebuild your rocket right before lift-off.

A common approach to starting a project is “let’s do this ASAP; we’re sure about it.” Obviously, without doing a discovery phase. Shortly after, this turns into, “oh, we’re not so sure anymore.” People want to see the results of the work ASAP for different reasons. Some have raised an investment round, and some had an unpleasant experience with other vendors, you name it.

But there’s still something in common. That’s the fear of missing out and needing more time, opportunities, or another audience. This is also partially due to the popularity of Agile and the need to get instant feedback. However, working in an agile way doesn’t mean working with guesstimates.

However, if we skip the discovery phase and the analysis of our needs, we’ll build something that we think is cool but already exists. This can also result in something that looks good on paper but doesn’t work on the technical level.

That’s why the IT project discovery phase, prototyping, and user interviews are critical both on the product and project levels. Another common thing – we start doing something, then stop for a minute and understand that something’s going wrong.

In business analysis, there’s an as-is state and a to-be state. These two let us know where we’re now and where our project is going. Knowing these two determinants, we can lay our path to improve the project. This is essential for the discovery phase project management.

People often draw up the to-be state without understanding why they want it in a certain way. So, what’s the main problem we’re solving in our as-is state? How often do we question what we’re doing in general? Using, for example, the 5 why method, we could save quite a bit of time.

Generally, we can divide people into 2 types: those wanting to start ASAP and skip the discovery phase of projects and those wanting to plan carefully first. How to work with each of those?

The ASAPers: ask them basic questions, even though they may seem silly: What are we doing? Why are we doing that? What will the new functionality bring to the table? These things seem obvious, but many people don’t consider them while doing the discovery phase of the project.

Every project should have at least one person who will constantly ask questions. Very often, if there’s no full-time BA on the project, the QA serves the role of the question-asker. If there’s also no QA – take the initiative into your hands despite your role.

If I know that I’m going to ask something that should’ve been answered long ago, I start with, “look, I may ask something stupid now – you can say that to me – but listen, is this correct?” Usually, the answer is, “you know, this is not a stupid question; we actually didn’t think about it.” And we start thinking about the problem together.

Other options of “stupid” questions for a discovery phase in a project can be:

• “Can you explain the concept/outcome like you would explain it to your kids?”

• A question with unrealistic boundaries, like “should I open the door to enter the room?” or “can we divide something by 0?” In the end, you may find that there’s no door or that we can’t divide other numbers by 0.
• “Can you schematically explain what you need,” which usually means to use a very simple scheme. An example is something like the water cycle.

The planners: try to switch them from thinking, “we should plan everything now” to thinking, “we can plan in phases.” Then we can finish some tasks first, check if we’ve done a good job, and move to the next phase. Here, Agile is the answer.

Or use the KISS (keep it simple stupid) approach. I had a great client who loved this approach and taught me a lot. Before doing anything, they asked, “what’s the simplest solution for this?” This way, you solve the real problem and validate your hypothesis. Next, you can work on the add-ons and improvements.

The current team did a discovery phase and estimated 100% of the needed scope as a few years of development. Later, however, we agreed to an MVP with limited functionality. On top of that, the MVP had an integrated library that allowed us to reach the results expected before.

Overall, the development time to provide users with initial functionality was around half a year. This was achieved by asking potential clients which functionality they couldn’t live without and prioritizing that.

Such an approach works great for doing something unconventional. For example, after using the KISS method, we’d often let the users test the feature only to understand that it wasn’t what they expected. Based on those results, we could redo the task to improve the output.

With the stupid questions, I suggest relying on your intuition and experience. Maybe you feel that something is off – ask about it. Or perhaps you’ve done something similar in the past, and something went wrong – ask how’s everything working now.

This will get easier as your relationship with the client improves. With time, you’ll also understand the best approach to asking questions. Better to make it clear during the discovery phase that you’ll be persistent in questioning things to ensure the project goes well.

Not to be Captain Obvious, but I’ll suggest some simple but effective things. The easiest ways to ask questions are:

• Use active listening patterns. This includes asking open-ended questions to encourage further responses, paraphrasing and reflecting on what has been said, and listening to understand rather than to respond.
• Each time you have a feeling that something is not matching the whole picture, ask a clarifying question
• If you aren’t comfortable asking questions during the call where everyone’s involved, note it down and ask later 1-to-1, or drop it in chat. You can start with, “I was thinking about what we discussed/I was reading my notes, and I have a question…”
• Use async communication, like comments in docs, emails, etc.

• And most importantly, don’t be afraid to ask. Better to ask and get obvious answers than regret not asking later. Be that pain in the *** because, in the end, everyone will be thankful to you.

I usually work as a part of an outstaff team. Therefore, I’m used to clients neglecting the project discovery phase and considering us as some people from the outside serving the purpose of helping hands, and that’s it. The clients rarely have a contrary view of us as full-on team members.

But for me, each project I work on is like my own baby. Thus, I consider how to do things best, which greatly helps. Always think about what you would do if you were in the client’s place.

If you’re a beginner afraid of looking stupid because of asking questions, just accept it. The truth is that many years later, you can still feel silly and not expert enough before asking a question. We’re all people, and we all can be wrong about something. It’s better to ask for clarification than remember when it’s too late.

Don’t be scared to make mistakes – it happens to everybody. The important thing is the conclusions you come to afterward.

The price of not making clarifications depends on the project time point. For example, once I was working on a project related to developing a new product, and the start was really rushed. We didn’t have time for the discovery phase as the client wanted their customers to see a finished landing ASAP. We were starting from scratch, though, so we needed enough time to prepare everything.

The client, however, just asked to realize what the designers had created. We asked, “okay, but how do you want to see your product in 3 months?” and the answer was, “I don’t know, but everything will work.” We had to disappoint them because that wasn’t the case.

I can’t talk about the project’s nature, so I’ll use the example of Instagram. The client wanted the text message function, even though we said that the primary purpose of Instagram is picture sharing. They still insisted they needed messaging the most.

Later, it turned out that users didn’t want to text; they wanted to post pictures. Only then could we switch our focus to that function. The first realization of something going wrong usually occurs after user feedback or when you just see things going wrong.

Here, we have two options. The first one, if you’re lucky, is having the possibility to repurpose the newly built functionality. For example, maybe you can integrate it at a different project stage.

The second and worse option is just throwing away what we’ve done. In such a case, even though we wasted some time, we started working better as a team, which is a big plus. And, of course, we got our lessons learned.

If you’re dealing with clients who love meticulous planning, you may end up doing something that has already been done. The more we delay the actual work, the more the gap between people who’ve done it already and us will be. To take the innovator position, we’ll have to do more.

It can be hard to start, I know. A personal example: I love painting, specifically doing paint-by-number pictures. But I always tell myself I should paint something myself. Then, I start choosing what I’ll paint, which paint I’ll use, the background music, and so on. In this case, you never actually start doing the work – all you do is plan.

At some point, you should stop planning and start painting. You begin working and enjoying the process, which motivates you to continue and achieve your goals. The same applies to projects. When we only plan things on paper, it can last forever and never seem right.

The best option to find out what went wrong is doing a retrospective. You’ll get your lessons learned, and the good thing is that you can do it both during a project and at the end.   

A key thing is not to be influenced by personal dislikes and blame others when doing a retrospective. Instead, break down the result and understand what the whole team should not do anymore.   

Another approach you can use is post-mortem. For example, your website failed in production, so you fix it first and then look closely at what went wrong. These are also lessons learned, just in a different format.   

A perfect discovery phase flow would be a client coming with an understanding of what problem they’re solving and who’s their user. Then, together, we start breaking down the solution in detail.

However, every project is different, and things will likely go wrong anyway. So, for me, a genuinely perfect discovery phase of a project is when the client is ready for it. Spending from 2 days to a week on the discovery phase can change the whole project’s flow.

I had a project where we had a sprint zero, which is comparable to the discovery phase. For a week, we had regular team-client meetings to look at what problem we were solving in more detail. It was an internal product, so we also interviewed company employees to understand their pain points better.

This way, the whole team had a good understanding of what we were working on. The client also had an opportunity to present their idea of the perfect end product. Then, our team made suggestions regarding that vision to optimize the result.

During that week, we came up with many ideas, eliminated some things, and ultimately had a roadmap for about 3 years. We also improved it later, already having solid building blocks for the project and knowing which result we expected.

My favorite tools for the discovery phase of an IT project are brainstorming, user story mapping, and basic prototyping. The latter is just taking sticky notes and visually mapping out what we want to do. You can do this by splitting the team into smaller groups, coming up with different results, and then choosing the best solutions.

Also, remember to take breaks during busy brain work. Sometimes we would leave the office, a new location for us as we were in the client’s city, and just walk for a few hours. We would talk and look at things, and sometimes it helped to come up with ideas for the project too!