Discovery Phase in Custom Software Development

The Discovery phase is an initial phase where we start gathering requirements from the client and understand the vision and concept of the project. This is a checkpoint to validate if the product is viable and what the target market for the same could be. Usually, gathering requirements is not straightforward. There are certain iterations while finalizing the scope, if these iterations are not understood or documented clearly it can bring many challenges or disputes at the later stage which can be the reason for the failure of the project too. So, it’s very important to start it right.

Let’s start with what is the Discovery Phase, Why we use it, and how we can eliminate failure or disputes.

What is the Discovery Phase?

There are many technical terms for this phase such as “Requirement gathering”, “Initialization Phase”, “Business Analysis (BA) Phase”, “Preparation Phase” etc. If we try to understand it in simple language, it simply answers two things. What needs to be done, and How will we do it? If we are on the same page with these “WHAT” and “HOW” questions, we can reduce the chances of disputes at a later stage.

The expected outcome from the Discovery phase is a well-defined scope of work that iterates the list of modules (WHAT modules to include) and flow (How it will function) with technical specifications (What technologies will be used for development).

What are the other phases of the project?

As per agile development, there are 6 phases of the project life cycle, and each phase has a different set of activities.

Why the Discovery Phase?

In many cases, clients or companies choose not to have the discovery phase as they think they are going to build a similar product or common product whose concept and features are similar and do not require more brainstorming or any more detailing.

Unfortunately, they end up in the following Situations.

1. Spending more hours than expected/ Going Over Budget

   Common Problem Situation.

   • When there is no Well-defined scope, there will be more surprises.
   • There might be some items that were estimated wrongly but were not identified earlier due to the elimination of the Discovery phase
   • Have to add some addons as things were not clarified earlier

   How can the Discovery Phase help here

   • A well-defined scope can help us estimate well, as modules will be clarified while defining the scope.

2. Too many Change requests

   Common Problem Situation.

   • When there is no discovery phase, there is no specified guideline to execute things which can lead to more changes
   • There might be some modules that are there in the reference product, but you didn’t consider them in your scope

   How can the Discovery Phase help here

   • The Discovery phase helps to identify what needs to be done and how we can do it. With this reference, we can decrease the change request and focus more on in-scope items.

3. Losing Trust of the customer/ Unpleasant relationship with the client

   Common Problem Situation.

   • Avoiding the Discovery phase increases the events where you have to renegotiate scope frequently with the client and creates a wrong impression
   • It can lead to a feeling where the customer feels they are being overcharged or being cheated with no transparency.

   How can the Discovery Phase help here

   • The project discovery phase will help to have the client and project execution team on the same page and help set the expectations clearly. When things are clear, trust is built between both parties.

4. Frustrated and Unhappy Team members

   Common Problem Situation.

   • By Avoiding the product Discovery phase, there will be no clarity for the team members, and they might get stuck with what to build and how to build
   • Or they might understand things differently, and it gets identified at a later stage, which leads to redeveloping the module.
   • It can be frustrating for the developers to redevelop the same module or work without clarity

   How can the Discovery Phase help here

   • The Discovery phase helps to identify How we’ll build it so the team members have clarity while starting the work. It can help us to develop as per clients’ expectations, and happy customers’ feedback is the most effective motivation for the team.

Who will be involved in the Discovery Phase? / Stakeholders involved in the Discovery Phase.

Stakeholders’ involvement depends on the organization and how they plan it. Usually, all the members who are responsible for creating and using the final product are the stakeholders while in the discovery phase. Stakeholders collaborate internally to define the scope of the product they want to build.

Stakeholder	Reason
Sales Team Member	Sales team members take care of cost-related things in a project, such as how much it may cost. How long it may take etc.
Business Analyst	BA team members help to analyze and validate the product requirements. They also help to document it or prepare the wireframes or diagrams to understand the flow.
Technical Team Member	Technical team members help to validate the product features and operations
Customers	Customers explain their desire to build a product and share their vision of the product
Investors	Investors can finalize the modules and priorities as per budget.
End users	End users can share their expectations and purpose of using the product
Developers	Developers can help validate the expected time to build the product and can collaborate with the client to understand the requirements.

How to execute the Discovery Phase?

There are many ways to execute the discovery phase, and there are no certain rules to execute the same, but as long as it gives you a clear specification, you can consider it right.

Here, we have some steps you can use as a reference.

Step 1: Identify the Nature of the Product and the client

You need to identify the nature of the client so you can understand how you can collaborate to discuss the project requirement. Some customers are not able to imagine things without having any visuals, and you might have to choose to create wireframes/ UI UX Design, etc. If the client is clear and can understand with some references, you can finalize things with a document.

Step 2: Start Documenting Modules for the Product

As soon as you identify how you want to move forward with the requirement gathering, you can start documenting the modules for the product. You can also include wireframes or designs if you have prepared for the product.

Step 3: Finalise Workflow and Tech stake

As soon as you finalize the modules you plan to develop, you can start finalizing how you want to develop them and what technologies will be used to develop the product. It is recommended to confirm the technology while in the discovery phase so we can know clients’ expectations and make them aware of what we’re planning and how it can be helpful for them.

Step 4: Component Identification

While working on software projects, certain third-party libraries and options can be used for the project/product development. These components can be paid for as well. It is recommended to make clients aware of these choices so that they can be aware of the monetary aspects associated with these as well. i.e., you are developing an application for video calling, and you plan to use X component, which costs $50/month and is a good match for selected projects, but you didn’t notify/clarify this with the client.

You confirm everything else and start developing, and when you are in the development phase to execute the project, you receive a request from the client to use the Y component, which costs 20/month but is not in sync with your requirement; now the client thinks that he has found something cheaper, and you should use that, and it goes on and on and on. We could avoid it if it were clarified in the discovery phase.

Step 5: Estimate the Scope of Work

Once you finalize the modules, technology, and components, you can start estimating the requirement to check how many hours it will take and how much it can cost. As this is the final step for the discovery phase, you must have the Scope of Work defined with details, including What needs to be built and how we’ll be building it.

What should be the duration of the delivery phase?

It purely depends on the project size and how we choose to move forward with it. If we plan to develop the full flagged product, it can be long, whereas if you just want to go with the MVP version (minimum viable product version), it can be shorter.

Usually, it takes approximately one week to 2 months’ time depending on the project size.

What are the deliverables of the discovery phase?

As we discussed earlier in the What is discovery phase, the expected outcome of this phase is a well-defined scope of work, however we can expect items below from the delivery phase.

• Scope of Work document/ System Requirement Specifications.
• Wireframes/Designs
• Estimation Sheet

What to Include in the Discovery Phase?

As stated earlier, the expected outcome of this phase is a well-defined scope of work. Basically, the answers are “What” and “How”. It should define what we’ll be building and How we’ll build it.

In Technical Language, define modules, Features, and Tech stakes. But the key point is to make sure that everything is clear and all the stakeholders are on the same page.

A Famous author once said:

Half-knowledge is worse than ignorance. – Thomas B. Macaulay

Similarly, half-defined or high-level discovery can lead to miscommunication or misunderstandings. Here are a few key points to cover in the Discovery Phase.

1. Wireframing

   Screen-wise wireframing can be helpful when you are in the discovery phase.

   Benefits to Company	Benefits to Customer
   It becomes easy to demonstrate how you are planning to build the product.	It helps to get an idea about how things will look like.
   It becomes easy to explain what features will be included and how they will work.	It helps to collect feedback from team members on wireframes rather than on documents.
   It helps to prepare the final design from Basic wireframes.	You can easily identify if anything does not match your expectations.
   It helps to define UX (User Experience) for all screen	It helps to understand the process/Logic of how the system/product will work and can be validated at an early stage.

   There are many tools available for wireframing with drag-and-drop features, such as Balsamiq, Visio, mockups, etc.

2. Feature/Module Listing with Limitations

   All we tend to do in the initial phase is to hide the limitations of the product, but it’s the ideal time to be transparent and list out all limitations along with the Feature details.

   Let’s have an example here.

   • You have a feature where you are allowing users to upload images/videos.
   • You mention in the scope of work that “Users can upload videos and images from the web app, and they will be played on the mobile app”
   • You did not mention that you can not allow bigger videos.
   • When you release the system for the customer’s review, the Customer Uploads a video of 10 GB and complains that it is not loading on the app, there is no upload progress bar, It takes a long time to load, there is no loader while it’s loading, etc.

   If you define the Limitation here as “You can upload video up to 2 GB, and it will only Support .mov and .mp4 format”

   It sets the expectations. If a client wants to upload big files, you’ll realize it earlier and will be able to accommodate it.

3. Define Technical Specification and Browser Compatibility

   We are in an era of gadgets, we have a vast range of mobile screen resolutions, iPad, tablets, laptops, smartwatches, etc. It’s hard to build a program/system that runs well on all devices, browsers, and resolutions.

   For the sake of transparency, it’s wise to identify and notify the client about what device support we can have for the program we’re going to build.

   There are many programming languages available to build a program/system these days. It’s also recommended to notify clients about which technology/programming language and version we’re planning to use to build the system.

4. Identify Third-Party Libraries and their dependency.

   Being in the programming field, we are privileged with many ready-made libraries, Themes, and services that can be used to build a product/system.

   It can be helpful to identify the third-party libraries/services that can be used in a project so we can analyze them with clients and make sure they are worth using.

   In most cases, clients are bearing the third-party charges. If they are discussed during the discovery phase – Clients can review the cost and plan to modify/remove any module from the scope of work.

5. Project Assets

   Developing any product/system requires some assets such as images, hosting server details, website content, email templates, SMTP details, etc.

   If all these assets are identified and listed with the details of who will provide what – It can be a lot easier while being in the development phase.

   It also helps to foresee the delay if any key assets are delayed.

   These are five key points we recommend considering while being in the discovery phase. Happy Discovery!

Awesome tips to follow for the Discovery Phase

We have some awesome tips for you which can be helpful.

• Make sure to communicate the limitations, too, and don’t show only the positive side of each module/feature. Make sure everyone is aware of the limitations too.
• Maintain 100% transparency while gathering requirements from clients. Make sure you are all on the same page. Ask multiple times if you don’t understand anything.
• Prompt Communication. This is the initial phase, and if there are delays in this phase, the stakeholders might lose interest and focus.
• Recite things till you are all on the same page. Make sure the stakeholders understood what you wanted to convey and that there were no miscommunications.
• Pro Tip: Read and Follow all four Tips listed above.

Summary

The Discovery phase plays a crucial role in figuring out the requirements, understanding the expectations of the stakeholders, and also keeping everyone on the same page before we proceed with the software development. Hence, it’s an essential step before we proceed with software development. If you have a software idea and are looking forward to building custom software with a talented team, starting from the discovery phase to the delivery of the project, let’s brainstorm over it together.