Discovery Phase: Stages, Values and Challenges

The discovery phase of any software development life cycle (SDLC) helps realize whether developers can fulfill the customer’s expectation as well as how much it can cost. The core business problem, specificity of a particular business domain, and technical requirements for the future solution—all can be explored via the project discovery phase. 

A clear idea of how the discovery process works can reveal the value the phase brings to the project. What do you do if a customer ignores or refuses to conduct the discovery phase? What difficulties do developers face during the process most often? And how do personalized approaches contribute to a successful discovery of the project?

Let’s address these and other relevant questions from the perspective of an experienced software development vendor.

What Is the Discovery Phase?

Also known as requirements analysis, the discovery phase is the most crucial step toward building a successful software solution. All info collected during the phase will determine the fundamental approach to a particular project. The conducted analysis allows developers to select both technologies and organizational methods for the best optimized SDLC. This is about proper planning of the entire scope of subsequent works with minimum possible risk. 

The discovery phase helps both software vendors and clients find an answer to the principal question: which problems of future users can our solution address? Despite the answer seeming to be obvious from the very beginning, real-life experience often says otherwise. 

The project management discovery phase provides both time and opportunities to clarify all project nuances, identify the general scope of work, and create a precise specification of the future system. All of this is ultimately reflected in the final outlined set of discovery phase deliverables. These may stretch from budget approximations to technical specifics, workflow scheduling, etc. 

At this stage, clients seek to clarify various underlying aspects of the project, like the format of development (e.g., native, cross-platform, or hybrid), product foundation approach (to reuse existing elements or to code custom structures from scratch), and others.

Discovery Phase Goals and Tasks

The discovery phase is about gathering and analyzing requirements, systematizing all the input information, and lots of planning that eventually clarify the big picture of the whole project and eliminates any early-stage uncertainty. The ultimate goals include the outline of approximate project time and budget boundaries, high-level project planning, and forming of the technical project implementation.

Based on these clarifications, essential discovery phase tasks are outlined, which may vary from project to project, yet include the following “golden-standard” efforts:

• Analysis of the project’s business aspects, which outlines what use the project brings for business—how it assists or streamlines it and list of stakeholders the project will serve
• Definition of functional and non-functional project requirements
• Project road mapping, which includes a ramp-up plan: delivery, budgeting and communication plans (which outlines communication channels, purposes, and participants)
• Other specific client-approved tasks such as a partial or full UI/UX design outline, vision of the project architecture, expected testing strategy, DevOps strategy, release plan, etc.

Deliverables

The deliverables to be presented to the client as a result of the discovery phase are based solely on the tasks underlying this project stage. If the main goal of the discovery is the planning of the development workflow, deliverables will respectively consist of various aspects of the process. 

And as much as a good set of deliverables is useful for clarifying the state of things, everything must be balanced—too many deliverables might be counter-effective, confusing the client and other parties instead of setting things straight. Here are the deliverables that usually result from the essential discovery stages:

• Requirements analysis deliverables: project features list with functional and non-functional requirements, estimation of the implementation effort, project vision and scope that covers high-level project needs, stakeholders and target user capabilities
• UI/UX deliverables: proto personas—generalized descriptions of the project’s end-users, customer journey map (CJM)—outline of project’s user interaction essentials, UX and UI prototypes
• Technical solution deliverables: system architecture—outline of the project’s components, its goals and interaction specifics, integration strategy—description of integrations, connected APIs, and third-party services and specific documentation if necessary, hardware specifications, security and privacy requirements—description of system protection and user privacy mechanisms
• Planning deliverables: team composition/ramp-up plan—outline of the team structure across different stages of development, collaboration plan—outline of communication channels, technologies, participants, and purposes, release plan— scheduled stages of expanding a live product with new functionality, release backlog—a description of post-release features and functionalities
• Other deliverables: QA strategy—types of testing involved and the testing schedule, DevOps strategy—a set of cloud-based services for development, testing, and production environments

What Sets the Bar for Discovery Phase Efficiency?

There can be three sets of criteria for the efficient, high-quality discovery phase. The first is formal criteria. This includes a proper discovery phase which is conducted timely in terms of the set deadlines and budgeting boundaries; all set tasks must be handled and translated into respective deliverables. The second is subjective criteria: the level of client satisfaction with all the implemented activities and the client’s trust in a development team built on deliverables defined earlier. And the last is objective criteria: results of the discovery phase—how much it helps the software vendor design and develop a new product.

Objectively, a truly efficient discovery phase is one that enables involved specialists to go by the roadmap without much deviation. If that’s the deal and the workflow runs well on all the deliverables and guidelines elaborated during the stage, your discovery phase was surely a work well done.

Do Projects Always Need the Discovery Phase?

Very often customers come to developers with minimum information about what they need and why—they only articulate nothing but vague desires. And while specialists are used to such working conditions, it limits the scope of visible milestones that should guide them to a high-quality project result. 

The discovery phase helps you understand a customer’s business needs as well as how the true business goals differ from the personal wishes of the customer. All of that requires thorough, timely research, which makes the stage essential to pretty much any project, whatever the shape and size.

As an individual compromise, the discovery phase can be minimized. The so-called “zero discovery sprint” (one of the relevant agile definitions) is possible when a customer requires quite a typical solution that the hired development vendors have former experience of creating. But in the case of an unparalleled project with complicated business logic that requires multiple iterations, the discovery phase is a must. 

Furthermore, the strictness of the project’s need for the in-depth discovery phase depends on a certain business domain. In the niches where either regulations or requirements for software keep changing constantly, the developers can hardly avoid a meticulous preliminary analysis. A project using cloud system integration for healthcare can be an illustrative case of such a situation: a solution should be as HIPAA compliant in terms of security rules as cloud-integrable in terms of the IT infrastructure.

How to Coordinate Customer Expectations and Project Requirements

It seems the majority can understand the project discovery process intuitively. However, intuition can hardly provide a worthwhile approach to requirements analysis. Often everything ends up with a semi-finished table created just for show in isolation from the actual functionality of the future software system. Such a discovery phase is nothing but a waste of time. 

So as not to repeat this erroneous approach, again and again, the issue should be addressed from another angle.

1. Change the View on Definitions

While reading a definition of requirements in Wikipedia (“…documented physical or functional needs that a particular design, product or process aims to satisfy”) many professionals can come to a conclusion that the discovery phase should result in a high-level description of working scenarios of the future solution. They start communicating with the customer to create a mass of inconsistent information while the solution happens to be designed based on their subjective understanding of the task.

At the stage of either testing or deployment, such an approach results in the customer’s reaction that every developer has heard at least once before: “This has nothing in common with what we would like to see in our solution”.

When software is built via the Waterfall SDLC, developers can reject all claims since the project documentation has been approved by the customer. But overall, what does it change? 

Once the discovery phase implies the analysis of requirements, the very view of the requirements should be changed. Instead of “needs that a particular product aims to satisfy” there should be “expectations of a particular customer that the product aims to meet”. In such cases, many opportunities to create what customers exactly want to receive seem to appear.

2. Use Personal Approaches to Customer Expectations

The above-mentioned discrepancies between customer expectations and the software vendors’ vision of a future solution can be mitigated by changing the way we understand project requirements. The following interpretations of requirements help improve the discovery phase’s productivity:

• Requirements are not about the system functionality but about a description of the problem that a particular customer wants to solve. The best way to embrace the customer’s requirements is to exercise empathy. Developers should tap into both the customers’ own terminology and their vision of the task. Due to such an approach, developers obtain an opportunity to use their knowledge and experience to create consistent and effective solutions.
• Requirements reflect the opinions of a group of people in most cases. Identification of all involved personalities and independent opinion surveys are oftentimes ignored by developers in the discovery phase. Moreover, the project sponsors are resisting the survey due to a lack of understanding of the importance of such efforts. The underlying cause of the most failures of either startups or corporate systems is just the difference between the opinions of project sponsors and the actual needs of future users.
• Requirements are mostly expectations—something that does not exist yet. The variability of the future is inherent in the very nature of people’s desires. Customers tend to adjust their expectations to the ongoing changes in the market. During the discovery phase, developers should manage customer expectations instead of just taking them for granted. It is not enough to collect and record all expectations. It is necessary to “sell” properly managed requirements to all project participants to make them remember exactly what they expect.

No negative connotations are available in the term “sell”: this is about the characteristics of a process, not about manipulation. Since requirements reflect the expectations of many people, someone’s interests can be potentially jeopardized. The discovery phase cannot be successful if the achieved compromise leaves someone either indifferent or unfavorably disposed towards the future system. 

Developers should remember one simple thing about the discovery phase: if after gathering all the requirements you cannot offer a holistic picture of the project to the customers, they will force you to follow their own ever-changing expectations. 

Why Vendors Claim Discovery Phase Necessity

Sometimes customers do not understand why they should pay for an additional study of their projects. They come to professionals and bring requirements, so the only remaining thing seems to be starting development. 

It is important to describe the negative outcomes of “zero discovery.” The no-discovery SDLC has to have a pumped scope of work as a rule, since developers have to make possible changes on the go. This leads to poorer customer satisfaction and interruption of projects at worst. Of course, the discovery phase cannot be a guarantee against all problems, but the risk of failure can be significantly decreased. If, as a result of a lack of discovery, the final product appears different from what the customer expects to receive, nobody wins: both the software vendor and the customer waste their time and money. Besides, the developers are missing other interesting orders and opportunities. Customers, in turn, start spreading negative feedback about the developers. Indeed, the lack of discovery is a “lose-lose” strategy.

What options do development vendors propose to the customers who keep refusing the discovery phase? 

• Propose customers share risks. Conduct discovery and represent the results to your customers. If they find the results worthless, the discovery phase appears at your own expense. If the results impress your customers, they pay for this phase..
• The discovery phase can be indicated as a standalone service beyond the scope of other contractual obligations. Some vendors offer this service with a certain discount.
• The worst case is you accept a contract without the discovery phase. When a vendor explains nothing to your customers, just include all possible risks in calculations. You can notify your customers about the approach if you feel they can get it right.

Difficulties Inherent in the Discovery Phase

The discovery phase has some typical difficulties worth knowing. They are never fatal if you know how to meet the challenge properly.

1. Lack of time. The majority of software projects are very dynamic with not much time to contemplate. The discovery phase should be carried out in certain steps when project managers and business analysts know exactly what follows what in the requirements analysis. The modalities of the phase depend on every certain project, but it is better to start from the business problem to be solved, go through the presumed user experience, and end up with the system’s description.
2. Lack of info about stakeholders/users. Oftentimes customers prefer keeping their business details secret. They do not want to (or cannot) reveal both the roles of stakeholders and users’ behavior. They require developing a certain system without understanding all possible nuances. It is worth insisting on the discovery phase to figure out the exact business model to correlate it with the future system. Find similar use cases, figure out roles, determine coordination between system elements, and choose appropriate technologies.
3. Not everyone on the customer’s side supports the project. Business analysts and project managers are often mistaken while supposing that all customer stakeholders are ready to answer questions. What if the company’s management does not believe in certain technologies? Maintaining a balance between different opinions can be tough. The best way is to encourage all stakeholders to discuss the project—only meaningful dialogue can dictate how to move forward.

Step-by-Step Process of the Discovery Phase

It is much easier to persuade customers about the necessity of the discovery phase when every team member knows what steps the discovery consists of. Even though any one-size-fits-all project discovery phase template can hardly exist, the following scenario is typical for the software development sector.

Business Model Elaboration

A conceptual description of a business model of the future product should be made first of all. It is more illustrative to create a scheme that shows all interactions between the product, infrastructure, consumers, markets, and stakeholders rather than to write a textual narrative. Such a clearly visualized business framework can facilitate both the discovery phase and forthcoming development. 

Mapping Users’ Behavior

This map shows all points of interaction between the future product and users. This is not about just the communication channels. This scheme should include a visualized user experience that covers the emotions, desires, fears, and motivations of users when they are trying to achieve their goals via the future product.

Prototyping UI

Projecting user flows is an optional yet efficient part of a discovery phase when schematically represented screens of a user interface help understand how users will be interfacing with the future product. Such virtual UI prototypes can simulate the behavior patterns of users. 

Prioritizing Functionalities 

This step is aimed at modeling user stories when functions and features of the future system are described. This determines what follows what in the development and testing processes.

Summarizing a Product Vision

The document defines the general goals of the project along with the suggested solution. It helps better understand both the potential of the product and its business promise. The product vision is critical for each and every team member from marketers up to QA engineers. Moreover, the document can reflect the very purpose of the discovery phase by providing customers with a clear idea of what exactly they will pay for at the end of the day.

Selecting Techstacks

It is never a dogma to select technologies that are proposed by the team at this stage—many tech stacks are overlapping in their capabilities. At the same time, the proposed technologies, architecture, infrastructure, ecosystem, and estimated loads are worth articulating before the final version of an SRS sees the light.

Conclusion

Any discovery phase appears useful when developers have no fear of asking customers many clarifying questions. Customers may resist paying for a deeper investigation of their projects by developers. Hence, it is crucial to explain what value the discovery phase brings to any project. 

A clear understanding of the difference between customer expectations and project requirements, personal empathy, competency in handling objections, and agility in project management all help developers convince customers that the discovery phase is never a waste of time and money.

Contact us today to make your ambitious software projects come true via the most effective SDLC with a comprehensive and meaningful discovery phase. Short time-to-market and reasonable pricing are included as well.