Discovery phase in the software development process

On average, large IT projects run 45% over budget and 7% over time while delivering 56% less value than predicted*.

M.Bloch, S.Blumberg, J.Laartz: ‘Delivering large-scale IT projects on time, on budget, and on value’ (Mckinsey research)

Most business owners generate a lot of ideas for software projects supposed to make more impact on their company. While it is easy to give rise to something, still, it is a challenge to validate this and bring to life then, adding some value.

Before starting any design or even MVP development, it is vital to clearly understand which problems a project addresses, what the target audience is, whether the solution adds value to its customers, etc. 

That is the Discovery Phase, which removes the gap between the raw idea and a solution defining project success.

Project discovery helps to:

    • Eliminate never-ending project scope: defining measurable expected results is the key factor to avoid project over time and release delays.
    • Sidestep budget overruns: setting clear goals and requirements is necessary for delivering a project on budget. 
    • Leapfrog software architecture and business logic mistakes.

When do you really need a discovery phase?

Odds are you might want to skip the discovery phase of the project. Well, it’s not such a good idea for most cases. Let’s puzzle out, when you really need a discovery stage.

  1. “I’ve got an awesome idea! But it’s still weak and needs reinforcing.” 

Literally, the project is in the ideation stage. Maybe you even have a few complimentary ideas and haven’t decided which one to launch yet. That is a classic situation when you can’t jump over the discovery stage.

You may still come up with the idea: ‘What happens if I decide to cut costs and skip this phase anyway?’

Go ahead in case you are running a micro-project. That may work for you. Still, if you are planning to run a more or less large-scale project, you take risks. At least your project might not meet stakeholders’ expectations.

2. You are planning to run an extreme project. 

Extreme project main distinctive features:

  • many stakeholders,
  • undefined outcomes and results,
  • uncertain goals,
  • undiscovered solution,
  • project tasks may change a few times a day.

Do not worry – only 2% of all projects belong to extreme type. Still, if you are running one, get ready to be nuanced, balance out stakeholders’ requirements, and do not skip these project development process steps – it defines project success, which is vital in case of extreme projects.

3. You are planning to run a long-term, complicated project.

Long-term, complicated projects usually

  • involve a few stakeholders, 
  • have complex goals, 
  • require varied preliminary researches, etc.

The Discovery phase handles all these requirements while its steps:

  • performing user research,
  • defining project goals and success factors,
  • outlining the value proposition,
  • gaining advantage from the broader context.

Passing the Discovery is strongly recommended for all project types. However, it is easy to get this activity wrong, and it becomes a waste of money.

To run the project discovery phase successfully, you need to:

  • make its cost and timing proportional to the overall project budget,
  • talk to all stakeholders (including hidden influencers), and balance their requirements,
  • spin off discovery into a separate project with its own goals and deliverables.


Key deliverables of the discovery phase

When the project discovery phase completes, all stakeholders have a clear vision and understanding of the next steps formally outlined in the SOW (Scope of Work). But SOW is not really a deliverable for the discovery.

Discovery deliverables vary depending on the project size, complexity, and other factors, and most likely, they will include:

Mind map

A mind map is a kind of diagram representing all project ideas, tasks, thoughts, etc. around one central Big Idea. It is not linear and allows us to visualize a project framework around its concept.

A mind map is perfect for visualizing an idea, presenting a conception, simplifying tasks, or outlining some documents.

Here is a sample of a mind map for mobile application:

Mindmapping is especially useful when you need to explore something unfamiliar together with the project team. That is what happens exactly during the discovery phase in a project: all stakeholders gather to outline their requirements, and a mind map helps to visualize and organize these very clearly.

Also, mind maps are the place to come back and recall the highlights for any team member at any moment of the project.

User Stories

The user story is a short and simple description of a software feature from a user perspective. User stories are part of the Agile approach. They help to switch from listing and naming features to discuss them and their value.

Usually, a team has some agreed template for user stories, for instance:

‘As a I want to , so that .

The Discovery phase is the perfect time for user stories: that is when the project starts, and all stakeholders and team members may take part in writing and discussing user stories. Some of them may become epics and will be split into smaller ones, while others will get directly to the product backlog.

User stories usually serve as pointers to the real software requirements, but they do not replace each other.


Clickable prototype

A clickable prototype is supposed to demonstrate the future interface and its basic features in a simplified form.



Such a prototype has no real code behind it. Still, it works well to show the application functionality and give its sense. Prototyping is the UI/UX designer activities, and he/she does it long before developers start their part of work.

Clickable prototype visualizes the project idea, concept, and main features, helping stakeholders to see how it looks in practice.


Software requirements specification

Software requirements specifications (SRS) is a document describing

  • the software (what it will do and how it will perform),
  • its functionality to meet all stakeholders needs (business and users).

Typically SRS includes:

  • the project goals,
  • its overall description,
  • feature set,
  • tech stack,
  • software architecture.

SRS is the fundamental document for the entire project. It keeps multiple teams on the same page: development, QA, operations, etc. 

Also, this document ensures all requirements are fulfilled and may minimize development time and costs.

Approximate budget & time estimation

The ultimate goal of the discovery phase is to give an accurate estimate of the project time and budget to create a product MVP or fully-featured product. This estimation comes after all discovery researches, and it is way more precise than preliminary was.

Nevertheless, these cost readings may change in some cases. For instance, a stakeholder wishes to add some functionality or feature during the process of development or wants to make changes in other conditions agreed upon beforehand.

Such changes unlikely will ruin your initial business goals but make some adjustments.


Scoping out during the discovery phase is an essential step for any project. Even the most forward-thinking team will want to get some idea of complexity and scale to whether spending resources on efforts makes sense.

Not to mention other stakeholders, for example, a company CFO who will definitely ask ‘what, how much and by when?’

If you want to 

  • eliminate most risks and bottlenecks in your project, 
  • avoid software architecture and business logic mistakes,
  • get the precise estimation of your project time and costs, reach out to our Business Analyst for a free consultation.