There is a well-known fact: the earlier a wrong decision is made, the harder it is to fix. The project's discovery phase is one of the first steps in building a backlog and starting the project. So, if you make a mistake at this step, it will be very problematic to fix it in the future. I want to share best practices for avoiding mistakes at this phase to eliminate future issues.

Vision

Every project discovery starts with understanding what exactly the project is about. So, team members must agree on what they want to achieve and roughly understand how to do it.

Typical mistakes include the lack of agreement between team members and too vague understanding of the outcome. Both these issues can be show-stoppers as they will lead to chaos on the following steps, misunderstanding between team members, and eventually to the project’s failure.

The receipt to do it properly is pretty simple to describe: team members must implement a decision strategy that will guarantee a single answer to every question. Finding a good strategy may take some time. However, it is crucial to do it from the beginning to avoid vision-related issues.

Flexibility

Every time you decide how the project should work, keep in mind that you may change this decision in the future. So, the decision has to have a certain degree of flexibility to have a way to adjust in the future. Such an approach is excellent at the beginning when not all aspects are clear.

There can be only one mistake here: make requirements too rigid. Full and precise vision is good. However, even if you are sure of what you want and how to do it, it does not guarantee that you will have enough resources.

Consequently, you should be ready for your decision to be changed in the future and plan possible adjustments and workarounds. So, you can keep the original idea, although maybe in a slightly different way.

Architecture

It is the first step when you start building something that affects the project from a long-term perspective. Of course, the architecture should be flexible as well. However, people sometimes forget that architecture should be able to change to accommodate new requirements.

There are two typical mistakes: making architecture too strict or too vague. Strict architecture does not allow an adaptation of new features, and vague architecture is not a good foundation for any application.

So, good architecture is somewhere in between: not too strict and not too vague. Sometimes it may not be an easy task, but you can always use real cases to evaluate it. For example, you may pick several use cases, check if your architecture offers a solution, and then intentionally change these cases to see if the solution still works.

Great Team

Finally, when you have a vision, flexible requirements, and reasonable architecture, there is only one important task left: find a good team to do this project. No matter how good the preparation was, everything is decided when real people implement the project.

There are many ways of finding a good team, but I prefer the one described by Jim Collins in Good to Great. There are tons of valuable advice there, but I would concentrate on only two. The first one: find the best leaders and let them lead the team. The second one: find the right people, they can do anything.

In my opinion, the only mistake you can make is finding an average or mediocre team. Unfortunately, there is no silver bullet to solve this issue. You need to find the best, and there is no other way.

These are four primary areas where you can mistakes during the discovery phase. Pay attention to what you are doing, follow the advice above, and you can do the project exactly as you want!