Discovery Phase in Software and Hardware Projects

There is a plethora of info available online concerning the software product development process. So with some time and effort, one may have a decent knowledge of how an IT project is progressing. However, there are much fewer resources available about the processes involved in hardware product development. This is paradoxical: we utilize tangible goods just as much as we do software.

Regardless of the field, the new product development process can be broken down into several general stages. Various authors single out five or more steps. They are idea generation, research, prototyping, testing and validation, and commercialization. At the same time, there is a fundamental difference between the development processes of physical and IT products: it is impossible to release a new version of a tangible product every day, as it is conceivable in software. Following the formulation of an idea, both types of products must go through a discovery phase as part of a product development strategy, which differs for IT and hardware projects. This is what the article will be about.

Let's get started by agreeing on the terms

Unless stated otherwise, the product is the end outcome of an idea's implementation. It might happen in stages over the course of numerous projects, or it can happen all at once in a single project.

A hardware project is one in which the goal of development is to create a tangible product. Because tangible products are difficult to develop quickly, the end outcome of such a project does not have to be them.

Typically, a project is broken down into stages, each of which has a distinct outcome aimed at producing a physical product. A completed stage, for example, could be the industrial design of a future gadget, or simulations of the processes that occur within it, as well as a built model for examination. These results are not tangible in the real world, but they are required in order to produce a physical product in the future.

‍

An IT project is one in which a software product or one of its components is created. Though an IT project is also broken down into stages, the end outcome of each and every stage is always a digital product.

Similar in essence, but different in the processes involved

It's not enough to merely go ahead and make a hardware or software product when you have an idea (although you can do it that way too, but it is very likely to go wrong). It's possible that these are not materials, tools, machinery or lack of software knowledge that are to blame for failure. Your decisions about component choice and arrangement may not take into account all the necessary features and functional requirements of the future device, while the written code may simply not work. Even if you are fortunate enough to realize all of your ideas, the inability to mass produce may demolish your "perfect" design, and the resulting system may not meet the end user's expectations. The discovery phase aids in detecting key constraints.

Before you start realizing an idea of a hardware project, it's critical to understand exactly what challenges the product solves and how to produce a solution that adds actual value. It’s the same for an IT-project, where a team starts gathering information to identify its vision, goals, and scope. This is why the discovery phase is such an important component of any project's life cycle.

The illusion of investigating an issue can be created in both hardware and IT projects. It happens when the team is supplied with a prepared answer or asked to produce a specific object when heading into the discovery phase. In such cases, the team typically does not describe the problem, instead attempting to explain its existence and find a specific solution. As a result, it's possible that the problem wasn't there at all, and the product developed isn't what was expected. Before conducting research, assess the proposed solution and present it as a problem to be solved. When constructing a gadget, for example, the Customer proposes using ultrasonic sensors to achieve an item detecting feature. Taking a step back from the solution, we should ask, "What do we want to achieve with this feature?" and, once we've gotten an answer, "How do we implement it?"

By posing questions, one can eliminate a lot of the uncertainty and assumptions. The discovery phase establishes the focus required to identify the real issue and build an effective solution.

However, the discovery phase may appear in IT and hardware projects at various phases of product development. The path to the discovery phase from an idea was described previously. We identify the necessary features of the future product and decide where to start when both projects are in the initial requirements collecting phase. However, the discovery phase in IT projects can occur in other situations as well, such as when a complicated system is extended. In this case, the discovery phase aids in understanding the present condition of the system, determining the scope of the change, identifying potential bottlenecks and dangers, and determining how to eliminate them. Of course, each system's design is unique, but the discovery phase will assist in understanding the inner workings. Studying the developed and manufactured hardware product for subsequent interior adjustments is highly expensive. As a result, early stages include harmonization of functional requirements, ergonomic design, layout selection, material selection, and component technology.

The technological readiness level (TRL) scale is often used to describe these hardware project stages, with TRL1 and TRL3 being the most common. The TRL4 prototype, which should demonstrate the soundness of the product idea and the feasibility of its technological implementation within the business criteria, will be a significant milestone. If the stage of incorporating additional features in the initial design has been ignored, an already built prototype with a TRL of 5 cannot be drastically redesigned. As a result, for TRL5 and up, the discovery phase should only be used to collect and clarify requirements that will affect future development. Functional analysis and changes to the product concept should only be carried out if the Customer has sufficient financial resources to redesign the product.

Differences in discovery phase processes between hardware and IT projects

Before starting the discovery phase, one should determine what needs to be investigated. For IT and hardware projects, we can distinguish between similar and dissimilar tasks.

The processes common to IT and hardware projects:

• researching the domain zone;
• defining the list of stakeholders;
• researching the Customer’s expectations of the product;
• defining the intended user audience;
• identifying dangers and bottlenecks;
• studying baseline data;
• identifying the requirements which might affect the business goals;
• competitor study;
• searching for existing studies;
• setting priorities and compiling the backlog;
• identifying constraints;
• estimating the budget and timeline;
• establishing the project roadmap.

There are also dissimilar processes in the discovery phase, which are described in Table 1. A check mark (V) indicates the type of project to which the process belongs. 

Thus, the fundamental distinctions between the discovery phases for hardware and IT projects are in the following:

• description of the operation principle of the product, design and and functions of its components;
• definition of the requirements for hardware, electronics, firmware, software;
• description of working modes and working area conditions;
• documentation of functional parameters: metrics, units of measurement, target value.

The importance of these stages is due to the type of a final product and scope of its use. A physical product has a number of technical parameters that must be investigated in the discovery phase before it can be manufactured. We concentrate on the product in this scenario. At the same time, it is the context of the environment that influences the discovery phase in IT projects. As a result, there is a greater focus on the external environment in which the future system will operate.

In rare situations, the eventual hardware product's scope may have an impact on the discovery phase. 

For example, we worked with a Сustomer who wished to build a robot that carries finished parts from one area of a warehouse to another at a set interval. We first researched the external conditions in which the robot will operate and specified the process in which it will participate. Only then we began designing the robot's internal mechanisms.

Gains derived from the discovery phase

The results of the discovery phase, like the processes involved, vary depending on the project type. The following artifacts demonstrate the major advantages of conducting the discovery phase in hardware and IT projects*:

• project plan
• product vision
• finished backlog
• product design ideas
• projected initial documentation
• architectural documentation
• rough estimate of project’s time and cost
• scope of work
• project road map
• technology stack‍

‍_{* depending on the requirements, the list may be expanded}

The ultimate set of artifacts is determined by a Customer's initial data and the project's goals. Conventionally, if a Customer already has product design ideas or a project roadmap drawn up, this job is skipped because it is no longer critical.

The approaches to the discovery phase in IT and hardware projects are similar because they begin with global business goals and objectives and end with specific user interactions with the product. This produces about the same artifacts with tangible project development benefits.

What’s more, the benefits, achieved as a consequence of the discovery phase, vary depending on the project model (agile, waterfall, ect.). If agile development is chosen, for example, an accepted Technical requirement may be one of the essential artifacts of a discovery phase in a hardware project. However, the same result in an IT project will be mandatory if the project is not agile.

Differences include the fact that the same artifacts can be obtained through various project types and various processes within them. In an IT project, for example, learning about the Customer's business will aid in the development of the product vision. For a hardware project, the same artifact will be obtained by defining hardware, electronics, firmware, software requirements.

Is it possible to do without the discovery phase?

The answer is no. The discovery phase impacts the success of a project by bridging the gap between its idea and its realization.

The Customer may not recognize the benefits of the discovery stage and, as a result, is adamantly opposed to this type of work. However, saving time by building a product without the discovery phase would not bring value to it. It would not assist in avoiding costly miscommunications about development goals as the project advances.

In hardware projects, the discovery phase, whether formal or informal, occurs whether it is planned in the first stage or just included in the design cost. A technical benchmarking and feasibility study are always conducted by designers and electronic engineers to determine what needs to be designed. In IT projects, the scenario is similar: a problem analysis is required to determine what and for whom the system is being created. The depth of this analysis will be defined only by the project's time and budget limits.

Thus, while the discovery phase in hardware and IT projects differs in terms of the procedures involved, the goal is the same: to help construct a product value that the end customer is willing to pay for. It assists the development team in lowering development risks in both types of projects and the Customer in defining what they want to get in the end.