How the Discovery Phase Defines Your Project’s Success

Building a good software project is not that easy without a quality blueprint behind it. Coding is only a part of the software development lifecycle. Before jumping into the development phase, there are also many other activities that the team should undertake to make sure that the project has a chance of success. One of them is the Discovery phase during which the project’s idea, vision, and feasibility are explored and established.

In the first half of the article, I’m going to cover the ins and outs of the Discovery Phase. This part is meant to show you the fundamentals of the Discovery Phase in software development and how its neglect may affect your project’s success.

What is the Discovery phase?

The Discovery Phase is made of the following activities:

1. Defining project goals: The first step is to define the project’s idea, main objectives, and determine what goal or goals the Product Owner pursues. This knowledge helps the team understand the product’s value at later stages of development.

2. Syncing vision. It’s essential to align everyone’s visions (ours and yours) of the product. To this end, we rely on the method of double verification. Where we thoroughly explore your needs (usually, this takes no more than a few meetings), and then the Business Analyst provides the documentation describing the project, which is further approved by the Product Owner. This helps ensure that everyone involved ends up on the same page by the end of the synchronization process. This approach is actively employed in both the Discovery Phase and later at development and maintenance stages. It is vital to note that the overall results of client-team cooperation must be fixed and clearly established in the project’s documentation.

3. Finding the best approaches to meet project goals: After gaining in-depth knowledge of what we should deliver and setting main priorities, we elaborate the optimal strategy for implementation, namely, the one enabling us to achieve the stated goals at minimum costs. High-level parameters shaping the team’s work usually include the budget, deadline, scope, as well as flexibility and scalability of the solution being delivered. The optimal balance among these varies depending on the project’s objectives. It’s best to start with an MVP encompassing a limited number of key features, which lets the Product Owner quickly enter the market, and after that, it makes sense to create a full-functioning version of the product. In this case, we usually prioritize the budget along with the deadline. However, when the project requires a full-functioning product that will be maintained throughout its lifecycle, with the support team growing continuously, the focus is placed on maintainability, scalability, and scope.

4. Building a project’s blueprint: Based on the described objectives and approaches, the team comes up with a development plan, including detailed requirements: engineering prototyping and technical specification. This stage is similar to making a blueprint of a house you are going to build. You can skip this phase only if you plan to construct something small (within 100-200 hours) and is concrete; for example, the standalone automation of a single simple process or PoC (proof of concept).

Why is the Discovery Phase required?

We have encountered many companies that have their projects underway and at the same time are looking for a new vendor. In the majority of cases (more than 80%), the number one reason behind that is a weak Discovery Phase or its absence. You might have run into young teams that suggest skipping it and jumping to the development phase as a way to reduce a project’s budget. All in all, working with a young team with insufficient experience can often entail one or several of the following problems:

The development team doesn’t understand a client’s vision and goals

It’s the most widespread and complicated problem. What you find is that after a few meetings and QA sessions, an inexperienced team will start the development phase. The problem here is that even when both of you seem to have agreed on the product vision in the documentation, in practice there are probably different things on each of your minds. Work gets started and very quickly issues arise, and it becomes clear how different each party’s vision is. Without proper planning and alignment of processes (teams working without the Discovery Phase often fail to establish consistent development processes due to their insufficient experience) the team members will also have a different vision. This problem will be a problem until synchronization in documentation is completed.

The lack of synchronization documentation often causes multiple edits on the fly. Even with qualified engineers, functionality will be developed extremely slow, and the code base will be poorly maintainable and scalable.
In this case, the result of a team that has skipped the Discovery Phase fits the abstract description specified in the contract – the abstract document that was drafted based on a couple of calls between the team and the client to capture the shared vision. However, due to internal inconsistency, the team spends much more time on the development. Which can cause a conflict between the client and the team and lead to the loss of money and time.

Make sure proper communication steps are established from the very beginning of the relationship to prevent:

● misalignment on vision;

● wasted time on features that aren’t necessary;

● poorly written code and unorganized databases.

Multiple changes on the client-side for business reasons

Changes the team has to make throughout project development usually occur for two reasons.
The first is the business environment where many factors can come into play. It is important to predict and adjust the product’s architecture to match how the market will most likely evolve. You should remember that it is impossible to avoid all flexible changes because their neglect will most likely degrade the value of the product. This is why agile methodologies are preferably employed in software development.

The second reason for change is the lack of a unified project vision. At the inception stage, the Product Owner has the endpoint to which the team is approaching, but not the detailed step-by-step path to reach it. The Business Analyst’s and UX Designer’s role is to fill the gaps in the team’s and the client’s vision and propose the most optimal strategy prior to the start of development.

A thorough Discovery Phase decreases the likelihood of the second type of change by 80-90% and helps foresee the aspects where more flexibility will be needed and establish project risks, which helps the client better understand the final budget and deadline.

Neglect by the Developer at this stage most often results in the following:

1. Confusion about the final budget and deadline. Multiple changes frequently occur throughout the software development process. Unless the Product Owner is ready for it, marketing campaigns and the project as a whole will be suspended because the budget and the timeline were calculated inaccurately.

2. Considerable increase in the product’s price. Changes are less cost-consuming when made at earlier stages in documentation (and don’t affect code).

A solution that is weak and isn’t flexible

This kind of difficulty takes place when the Architect is not involved in the Discovery Phase. Besides a good understanding of WHAT the team needs to design, the Architect helps you understand HOW they will do it and defines the most optimal approach to implementation.

The choice of an optimal approach is always a balance among numerous factors (follow this link for more information) and there is no silver bullet. The more competent specialists that are involved in laying the foundation for the system, the better your product’s architecture will be.

In my experience, the most common risks facing our clients in their previous collaborations are as follows:

1. Inflexible solution with lengthy maintenance and long-term development. This type of solution considerably slows down the development speed while increasing project costs and often requires extra spending on refactoring.

2. Overly flexible solution where it is not needed. This type of solution entails a substantial increase in costs and complicates the system by making it more complex, which increases the final budget and postpones the deadline.

3. Inflexible solution with overly flexible functionality. This type of solution leads to a tug and pull situation combining the two issues stated above into one.

4. Low-quality software architecture or its absence. This type of solution is usually a result of the Architect’s insufficient expertise. This scenario leads to a growing budget and timeline at the development stage.

Unmet deadlines and exceeding budget limits

When nobody establishes requirements nor elaborates a development plan with approaches to its implementation, the project estimation structure is borrowed from a previous or similar project. Our practice shows that this kind of estimation is often overly optimistic, which leads to unmet deadlines and an exceeded budget. Usually, the Product Owner can detect the problem before the budget is completely spent but functionality will only partially be delivered, which creates numerous problems for both the new team and the Product Owner.

To estimate the project more accurately, it’s necessary to break down the solution in advance, determine the basic approaches to its implementation, and conduct additional research. This allows you to estimate the costs for every single software component. However, even the most solid approaches do not guarantee a 100% transparency into what the issues will be introduced as the project moves forward.

Impossibile to implement the project for technical or legal reasons

There are cases, however, when the product’s implementation is impossible by default because the business model is not compliant with regulatory requirements or technically infeasible, especially when the product should be integrated with third-party software that is closed by nature and has no integration options. In this case, the lack of the Discovery Phase entails more expenditures on the Proof of Concept because the team started working on the product before it was realized that the product could never be completed due to technical or legal reasons.

For further inquiry

Computools’s expert team sees the Discovery Phase as an obligatory stage in every customer software development project, as it substantially decreases the final price of the product and proves its feasibility. Later, we are going to go over the other aspects of the Discovery Phase and go into the deliverables that a client should receive by the end of this stage. If you are interested in other advantages of custom software development, including the Discovery Phase, do not hesitate to contact us via info@computools.com to get a free consultation on your project.