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.
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.
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:
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:
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.
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.
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.
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.
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:
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.
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?
The discovery phase has some typical difficulties worth knowing. They are never fatal if you know how to meet the challenge properly.
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.
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.
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.
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.
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.
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.
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.
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.
Configure subscription preferences
Trends & Researches
Interactive NLP chatbot empowered with conversational AI for web, mobile, and desktop that accelerates internal operations.
Data warehouse optimization for enterprise allowed business stakeholders to make data-driven decisions using up-to-date data and provided enhanced capabilities for the reporting system.
Telemedicine application that allows getting affordable, real-time health advice from medical experts round-a-clock using internet connection.
AI-powered IoT system based on the Salesforce that automates routine processes for landlords, reduces energy consumption, and extends equipment lifespans.
E-learning platform for enhancing the learning process with customized content options, vast testing capabilities, and market-leading pedagogy methods.
Creation of web applications containing maps that visualize pavement condition data and show a moving vehicle in real time
Conspectus is a cloud revolutionary software for the construction industry that provides a new approach for managing construction specifications.
Web platform for building curricula with pre-built 3D lessons and slides from anatomy educators across the globe.
Developing a fully-fledged and secure financial platform for making payments across 36 European countries via SEPA, FPS, and BACS payment systems.
See more success stories
Our representative gets in touch with you within 24 hours.
We delve into your business needs and our expert team drafts the optimal solution for your project.
You receive a proposal with estimated effort, project timeline and recommended team structure.