-The methodology presented in this paper aims at supporting the whole needs and the Stakeholder Requirements definition in product development or product extension projects. To achieve that goal, the methodology forces to take into account the relevant Stakeholders and the Product Life-Cycle phases they impact on for that product. The paper shows a practical example taken from a real product extension project where the methodology was used. Since the main inputs for product extensions usually come from the marketing department, it resulted to be very effective in broadening the perspective. Thus it ended up in a holistic list of requirements, covering the needs of all the Stakeholders. Requirements frame the development problem, hence, as more they are complete as less failure risks there are. The methodology requires further experiments in other industries to prove its generality. Nonetheless it is expected to provide great support in product extension activities by lowering failure risk and by helping in satisfying all the Stakeholder needs.
An artifact that is produced by a company and fulfills needs of some stakeholders is called Product. It consists of a series of interconnected features or functionalities and it is identified within a context and applicable in specific value chain. A product, like any other evolving thing, is characterized by a life cycle that starts with the conceptualization and development and finishes with the decline phase passing through growth and maturity (Figure 1). As shown in the figure the maturity phase is usually characterized by a maximum in sold units followed by a declining trend. Thus companies are very interested in keeping the growing trend as long as possible. For this reason in the maturity phase it is possible to see a product renewal that can consist of extensions of the product functionalities/features.
The product extension is usually needed because, even if the general product concept could remain valid from a marketing perspective, the change comes from the market in terms of new requirements or needs from customers (e.g. improved performances, side functionalities, user or technology maturity, etc.). The market requirements are the starting base to make considerations on the product evolution. However a structured engineering methodology is useful to secure that all the requirements from all the identified sources are captured and addressed.
The presented methodology aims at enabling the analysis
and development of a list of criteria and drivers to understand
the future evolution of the product. The methodology is
requirements driven and puts in correlation the product life
cycle phases and the company value chain. The output of
the methodology application is a list of requirements mapped
on the company value chain and product life cycle. From
the analysis of the map it is possible to derive the product
evolution and to address the solution to the right direction. The
extended product shares with the parent one the same reference
architecture and functionalities. Thus this methodology might
be integrated with others for the Architecture Management of
the product [
The associative network model, explained by Ref. [
Many authors agreed on the risks related to such practice,
though the product extensions resulted to be less risky than
the brand one. Nonetheless, it is expected that those risks
are similar, though with a different magnitude, in both cases.
Diluting the brand/product image, undesirable associations
and cannibalization of the existing portfolio resulted to be
the top of the list ([
Ref. [
Finally Ref. [
METHODOLOGY
The introduction of a new product or the extension of an existing one is usually driven, from a generic point of view, by the marketing department. They provide the list of needs that usually in later stages of the product development activity are translated into requirements. The main source of those inputs comes from customer, market and competitor intelligence activities. In order to have the full list of needs, other points of view should be taken into consideration (e.g. Customers service, legal department, supply chain, etc.).
The proposed methodology helps in providing structure to the needs mapping into the Product lifecycle phases while considering different points of view in the company value chain. It is composed by the following macro steps: High Level Needs identification Extendable Platform Product choice and its relevant life cycle stages identification Stakeholders matching with LC phases Needs further detailing in requirements
1) High Level Needs Identification: The first stage of the methodology consists on the identification of the needs (internal or external) that are the reason to start the product extension. In general the needs considered in this stage are results of marketing department activities aiming at scouting and analyzing new business opportunities or strengthening the existing ones (e.g provide more appealing cars by introducing infotainment technologies or improving smart-phones performances by introducing new generation hardware) as per Figure 3. The result is created by using marketing tools like interviews, scouting of competitors or similar businesses (e.g food and pharmaceutical for packaging business), business intelligence simulations for trends, etc. 2) Extendable Platform Product Choice and its relevant life cycle stages identification : In this stage the methodology is divided in two sub-activities:
Relevant life cycle stages identification
The first activity is simple in theory but critical from the company point of view. In fact in this activity the project selects the platform of the product to extend. The choice is really dependent on how the company organized its products and related portfolio as well as its development operations. The output of this activity are the platform of the product (Figure 3) to be extended and the related list of stakeholders (Figure 4). It is important to highlight that by selecting the platform and generating the list of stakeholder we are implicitly considering the company value chain.
The second activity is the identification of the relevant life cycle stages of the product. We are speaking about “relevant” because maybe not all the product life cycle stages could be involved in the product extension. In Figure 5 the common product life cycle stages are indicated. 3) Stakeholders matching with LC phases: In this step we put in relation the product life cycle stages with the stakeholders in order to understand and match where in the life cycle of the product there is a stakeholder’s need to be documented. The result is the SHLC matrix in Figure 6. As shown in the example not all the stakeholders could be involved into the extension. Moreover it is not given that all stakeholders are interested in every life cycle phase. The formalization of the needs starts at this point of the process. 4) Needs further detailing in requirements: Last part of the methodology supports the need collection by extracting them from the stakeholders vs lifecycle matrix. The outcome results in a list of needs per stakeholder and lifecycle phases. A sample need list can be seen in Figure 7.
Once the list is complete the project can start analyzing each need and develop the proper requirements linked to it, according to the analysis phase in the Systems Engineering process.
The presented methodology puts in correlation the product life cycle phases and the company value chain. The output is a list of needs mapped on the company value chain and product life cycle. From the analysis of the map it is possible to address correctly next project activities like the requirements analysis. This simple best practice can be helpful for both new products and product extension. It guides the project team to avoid loosing information during the needs collection and before developing the project requirements. The figures shown in this paper as example are taken from a real industrial context where the methodology was applied in order to develop requirements for an extended product.
Another application not yet fully explored consists of product extensions in the shape of new services to be integrated in existing products. That is because it gives a structured way to collect and manage information that can be applicable to any type of requirements definition problem. In general the methodology can contribute to reduce the risk of inconsistent or non relevant information in the initial phases of any product development project.
Fig. 7.
Example of needs captured from the customer correlated with the LC stage of the product