THE ROLE AND IMPORTANCE OF STAKEHOLDERS

IN PRODUCT DEVELOPMENT

Patrik Nilsson and Björn Fagerström

Engineering and Industrial Design

Product and Production Development
Chalmers University of Technology
SE-412 96 Göteborg, Sweden

Abstract: Today, product development is a complex process: the designer continuously

needs to consider new demands from different stakeholders and analyse how these demands
can be fulfilled. Gathering and sharing stakeholder information is important, but is only
beneficial if the information is used effectively. This is not a straightforward task. Information
must be shared across design functions, and all involved need to develop a common
understanding of the evolving design and the importance of particular stakeholders. This
process relies to a large extent on the individual designer's intuition since there is lack of
effective formal tools to support this.
We argue in this paper the need for a holistic view, in order to manage all criteria, considering
relevant perspectives and interests. To support this holistic view, we have developed a model
that provides a common understanding for stakeholders involved, together with the
requirements, functions and systems of the product being designed. This model will help
facilitate the information sharing between members of extended design teams. Based on this,
the model will support the decision-making process, and help the design team balance the
interests of different stakeholders and the related functions. The model has been applied in an
industrial case study.

Key words: product modelling, stakeholders, requirements management, and information

sharing.

Introduction and motivation

Product development is one of the most important activities in an industrial company. It is a

key for future success. The ability to make competitive scenarios of future market demands
and to continuously adapt to new demands is also a critical factor for success. Furthermore, it
is well accepted that satisfied customers are a key characteristic for success in the market.
However, although we need to focus on customer requirements, we must not in so doing
forget to look at profitability (Wallace, 1995). Therefore, we argue, it is important to consider
other stakeholder needs and not only the voice of the customer in order to create a well-
balanced product. In this process, we need to identify the relevant stakeholders and their
relation to the product. Furthermore, we must determine the requirements of each stakeholder
in a life cycle perspective. Normally, there are conflicting requirements from different
stakeholders. These have to be negotiated and balanced in order to develop a competitive
product.
Despite the fast development of information technology, there are still few software
tools that support the dynamic early phases where stakeholder needs and requirements are
identified and conceptual solutions are evaluated against the requirements. The development
of CAD systems has been driven by the attempt to define the product towards manufacturing
and assembly, at the neglect of other aspects of the design process. Furthermore, most
commercial CAD systems are successful in dealing with geometric information, rather than
aspects of the design process (such as function analysis, concept generation and exploration).
However, commercial systems for Product Data Management (PDM) have lately been
developed to support a more general handling of documents and objects created during a
design process. To support the dynamic early phases, a model is needed that provides a
common understanding of involved stakeholders, together with the requirements, functions
and related sub-systems.
This paper aims to describe a holistic model that provides a common understanding of
different stakeholders involved, together with the requirements and the evolving design. The
model is based on objects instead of text documents, as are frequently used. This will give
better transparency, flexibility and usability.
The remainder of the paper is structured as follows: the next section gives an
introduction to stakeholders in the product development process, section 3 and 4 describes
how to manage different stakeholder interests, section 5 then presents a case study that was
made at Envirotainer Engineering, Inc. in Sweden, and, finally, the conclusions are presented
in Section 6.

Stakeholders in the product development process

Many authors argue in favour of a holistic view during the early phases of product
development, taking into consideration as many perspectives and interests as possible
(Harding et al. 2001). The design of a product often starts with some general project
objectives and a set of stakeholder needs (see Figure 1). The stakeholders’ different needs will
then be translated into more detailed product/system requirements. The project plan will
propose some early work packages in order to start the work at certain sub-systems. The main
objective of the designer is to produce a design that meets this need within the limits of
available resources. However, it is also important in early phases that the designers look for
alternative work packages and product architecture in order to balance different stakeholders'
interests and to consider different life-cycle aspects. When the product architecture is
determined, the detailed design followed by verification and validation takes over. The
Product Data Management (PDM) system is used to integrate various kinds of information
generated and exchanged during the development process.

Product planning and project

planning
External
Product development process stakeholders
(including the
customer)
Internal Production
stakeholders

Product model
PDM system
Stakeholder/
Requirement model

Figure 1. The product development context

 The explicit result of the design process is product description, that is, information for
defining the product. Product description is usually represented in the form of drawings, CAD
data, or product models. In general, the term product model often refers to geometry-oriented
and feature-oriented models. A more accurate description of a product model is a model that
can describe all information representing the product throughout its life cycle (i.e. from
design and production through to use and disposal) (Isaksson et al. 2000). Designers need to
work towards sharing a common vision of the product. This means not only the geometry, but
also required functionality, requirements, etc. as quickly as possible. The product-oriented
information model presented in this paper could potentially solve this need for a common
vision of the evolving product.

Managing stakeholders in the product development process

As previously argued, in order to get a well-balanced product, it is necessary to take a broader

approach, considering not only end-users, but also all the other stakeholders throughout the
product's life cycle. The stakeholders act according to their interest. They use their power to
influence the product in the direction they desire. The expression stakeholder has become
increasingly fashionable, and is often referred to in various contexts. This variety in the usage
of the stakeholder concept is interesting, as it explains how different meanings may now be
assigned implicitly or explicitly to stakeholders. This makes it difficult to disentangle what
the concept actually means in a given concept (Pouloudi, 1999).
We define a stakeholder as: any group or individual that can affect or is affected by
the product throughout the product's life cycle. A stakeholder could either be from the
external or internal organizational environment. Stakeholders could also be regarded as
primary or secondary. Primary stakeholders are those stakeholders that have a direct stake in
the organisation and its success. Secondary stakeholders are those that have a public or
special interest stake in the organisation. Much literature in the strategic management area
discusses organizations in terms of stakeholder models. For further definitions of stakeholders
in various fields and related literature, see Sharp et al. (1999).
We propose the following process in order to manage stakeholder interests (this process
has been used in this study):

§ Identification of relevant stakeholders and their relation to the system

§ Determination of the stakeholders’ needs
§ Establishment of a stakeholder and requirement matrix
§ Balancing of the stakeholders’ requirements

Identification of relevant stakeholders and their relation to the system

Failure to identify a stakeholder results most probably in missing requirements. It is vital that
the relevant stakeholders be identified and involved in the specification of requirements
relevant to their role. The actors involved should always be aware of the difference between
what they perceive as a need and what the stakeholders perceive. Different stakeholders
interact with each other and are related in various ways. Interactions between them include:
exchanging information, products, or instructions, or providing supporting tasks (Sharp et al.
1999). The information regarding the stakeholders and the nature of their relationships and
interactions must be identified and documented.
Determination of the stakeholders' needs

When the relevant stakeholders have been identified, their needs must be determined. To
support this process, a number of methods for gathering and collecting the information from
the different stakeholders exist. Those methods include interviews, focus groups,
questionnaires, etc. which are well documented by other authors (Harding et al. 2001). There
are also methods for ensuring that no vital requirements are forgotten. Checklists are one
example.
Traditional customer-orientation focuses on the articulated needs of current customers.
To develop an understanding of future customers/stakeholders, companies must identify these
potential customers/stakeholders and their requirements and functions.

Establishment of a stakeholder and requirement matrix

When the information from the stakeholders has been collected, it needs to be transformed
into measurable and solution-independent engineering characteristics. A common method for
this is Quality Function Deployment (Akao, 1990). From a research point of view, the QFD
methodology is limited to addressing only the customer satisfaction issues as it targets the
customers’ needs.
In order to establish the influence each stakeholder need will have on the requirement of the
product, a stakeholder and requirement matrix is made. The matrix consists of the different
stakeholders, together with their needs/requirements, along one axis. The relative importance
of each need/requirement is estimated. The stakeholders are also divided into external and
internal. Each stakeholder need is then translated into technical requirements. Those
requirements are entered along the other axis. Each requirement is either considered as a
functional requirement (FR) or a constraint (C). The relationship between the stakeholder
needs and the requirements is thus established and entered into the body of the matrix.

Balancing of the stakeholders’ requirements

The proposed matrix shows the relative importance of different needs. That importance in
turn illustrates the significance external and internal stakeholders have. There must be a
discussion and trade-off between different stakeholders and their needs. The fact that
customer needs are collected and distributed to the members of a design team does not mean
that a product will be designed that customers will want to buy (Harding et al. 2001). Instead,
a rich picture of all the stakeholders is important for the team. The team can then more easily
share information about different requirements and design objectives. It is important in the
early phases to ensure that all team members have a common vision for the product, its
required functionality, performance, etc. It is also essential to have an understanding for
which stakeholders and requirements influence which functions and sub-systems.

The proposed product-oriented information framework

The collected stakeholders’ needs are listed in a stakeholder specification. The needs will
affect the product throughout the product's life cycle (i.e. from design and production through
to use and disposal). The needs are translated into more measurable requirements in the
requirement specification. The requirements are classified as functional requirements (FR) or
non-functional requirements (constraints, C).
It has also been observed that designers often shift back and forth between abstract and
concrete reasoning and models (Ehrlenspiel and Dylla, 1993) and that function and form co-
evolve during the design process. Moreover, research (Nidamarthi, 1997) suggests that the co-
evolution of requirements and solutions reflects (1) the way designers understand the problem
and (2) the way they attempt to fulfil the given requirements. The function-means structure
shows this iterative and evolutionary nature between function and solution. The function-
means structure consists of three different objects: functional requirements (FR), means (DP)
and constraints (C). Functional requirements (FRs) are defined as what a product, or an
element of a product, actively or passively does in order to contribute to a certain purpose.
They create an internal or external effect. They also motivate the downright existence of a
specific solution. In contrast to functional requirements, non-functional requirements (here
referred to as constraints) do not have specific solutions. Rather, they are fulfilled by
functionally driven means. They bind and add value to the solution space, such as weight,
cost, reliability, safety, ergonomic, etc. Means (DP) are the entity, physical or abstract, chosen
to fulfil a specific functional requirement. One example of an abstract entity would be
software. Examples of means include the organs (= “function carriers”), sub-systems,
components, or features that constitute the design solution.

Case study

The purpose of this study is to demonstrate and discuss how the model can be used during the
design of a system. The case study utilises data from a project performed at Envirotainer
Engineering Inc. The company operates in the market for Air Cargo Temperature
Management. Envirotainer offers global solutions for the air transportation of temperature
sensitive products in unbroken cool chains. The product that was selected for the case study is
one of the top-of-the-line products, the RGX 20-feet container. The model has been evaluated
by using METIS (NCR, 2003) software. METIS is a commercial enterprise and knowledge-
modelling platform based on an object-oriented approach.

Different stakeholders and their relation to the overall system

There are various stakeholders, each with different types of “stakes” in the decisions made
during the development of the RGX. By nature, the external stakeholders are normally more
difficult to identify and understand than the internal. Therefore, the information about the
main external stakeholders and the nature of their relationships and interactions were
identified. Figure 2 shows the complete model for the system. However, only a small number
of all the relations are shown in order to increase the visibility.

The different stakeholders are identified and grouped into either external or internal (see item
1). The key external stakeholders are:

§ air cargo carrier

§ authority
§ end-user
§ forwarder
§ ground handler
§ legislation, and
§ producer of goods
 1 3

2 4

Figure 2 The complete model over the system

The key internal stakeholders are:

§ design
§ manufacturing
§ leasing of container, and
§ sub-contractor

These stakeholders generate different requirements, and those requirements are a part of the
requirement specification (see item 2). The requirements will then define a number of
functions and corresponding solutions, together with a number of constraints (see item 3).
The overall function for the RGX container is to ‘allow for door-to-door shipment of
temperature sensitive cargo´. This, in turn, requires new functions at a lower level. These core
functions at the next level are: ‘provide heating’, ‘provide cooling’, ‘control
temperature/humidity’, ‘provide cargo compartment’ and ‘enable air transport’. The
following sub-systems solve these functions respectively: ‘electrical heating’, ‘AC unit’,
‘control system’, ‘cargo compartment’ and ‘bottom structure’. These sub-systems have been
further decomposed where appropriate. The major constraints are 'weight', 'reliability', 'cost'
and 'airworthiness certification'. Finally, each sub-system is then materialized by a number of
parts and linked to the part structure (see item 4).

Internal and external stakeholders and their requirements

A stakeholder and requirement matrix was made in order to organize and structure the
different stakeholder needs (see Figure 3). This matrix shows the external and internal
stakeholders and their individual needs organised in rows. The relative importance of each
need is also estimated as high, medium or low. This in turn will give the importance of
different stakeholders. The stakeholder needs/requirements are then translated into
engineering characteristics. Each engineering characteristic is either considered as a
 Figure 3 Stakeholder and requirements matrix

functional requirement (FR) or a constraint (C). The relationship between the stakeholder
needs and the engineering characteristics is thus established and entered in the
interrelationship matrix as arrows.

Linking requirements to the product model

Normally, the resulting specifications become different paper-based documents listing all the
requirements. Such lists of requirements are difficult to validate. In addition, they do not show
the relationship between the requirements (Schachinger and Johannesson, 2000). Model-
based specifications, on the other hand, give a more complete picture and understanding of
the system being designed. This will lead to a more common view of the future product. A
proposed revised requirement will be traced to the related system (see Figure 4). The sub-
system 'AC unit' solves the function 'Provide cooling’, which is required by the stakeholder
'End-user'. There are a number of non-functional requirements (constraints) attached to the
system that have to be fulfilled. It is also possible to see what parts the AC unit consists of.
This makes it possible to involve only the appropriate personnel to deal with, for example, a
requirement change or part modification.
Balancing stakeholders needs

The proposed stakeholder and requirements matrix shows the relative importance of different
needs. That importance in turn illustrates the significance external and internal stakeholders
have. However, there must be a discussion and trade-off between different stakeholders and
their needs. The fact that customer needs are collected and distributed to the members of a
multi-functional design team does not mean that a product will be designed that customers
will want to buy. Instead, a rich picture of all the stakeholders is important for the design
team. The team can then more easily share information about different requirements and
design objectives. It is important in the early phases to ensure that all team members have a
common vision for the product, its required functionality, performance, aesthetics, etc. It is
also essential to have an understanding for which stakeholders and requirements influence
which functions and sub-systems (see Figure 4).
 Figure 4 Analysis of AC unit

Traditional customer-orientation focuses on the articulated needs of current customers. To

develop an understanding of future stakeholders, companies must identify these potential
stakeholders and their requirements and functions (see Figure 5). New or optional functions
can be included in the model at the appropriate level in the hierarchy. By adding a new
function, the path will be altered on all lower levels in the functional decomposition where the
new function is needed.
Adding new functions to the hierarchy will allow for the exploration and investigation
of what effects are associated with introducing the new function. This will also make it
possible to trace backwards and see what requirements and stakeholders will be affected by
the new function.

Evaluation of new functions

Once a new or optional function has been established, it must be evaluated to make sure that it
adds more value than the cost associated with implementing it. It should be noted that some
functions are mandatory, and integrating them as cost-effectively as possible is essential. In
order to do this evaluation, we use a cost-value graph to plot the existing versus new
functions. Fujita and Nishikawa (2001) have also used this type of cost-value graph. The
proposed function ’provide cooling’ for the RGX can be solved in many ways. The cooling
system is based at present on a traditional cooling machine with compressor cooling (AC
unit). The present system operates on an on/off regulating principle. An optional functionality
is to have the function ‘provide proportional cooling’. That can be solved with three
compressors that can run separately or parallel (i.e. provide different levels of cooling). The
cost of this function will increase compared to the existing one. However, the value will
increase more in relation to the cost (see Figure 6). The cost will increase more than the value
regarding 'Function Y' and 'Function X'. However, the customers might interpret this
differently.
 25

Function
20 X
Future
need

Relative Cost [%]

15
New function

O O Existing function

10 Function
Not served Y
stakeholders
O Proportional
5 cooling

Served
O
Current stakeholders 0
need
0 5 10 15 20 25
Current Future
functions Relative Value [%]
functions

Figure 5 Moving towards new functions, Figure 6 Cost-value graph for existing
needs and stakeholders versus optional functions

Managing sub-suppliers with the model

It is quite difficult and time-consuming to make proper design briefs for all involved sub-
suppliers in an entire project and then expect the project to run smoothly. There are always
questions and discussions that follow, for rather independent and modular designs as well.
The proposed model will support not only these early phases, but also the later continuous
project updates that follow.
It is an advantage that the hierarchical nature of the specification is graphically
illustrated (see Figure 4), and that only the appropriate information needs to be transferred to
the sub-supplier. The amount of information needed could be seen as the functions and
constraints for a certain sub-system and the related stakeholders. It is also quite valuable to
have the dedicated constraints when designing a certain sub-system. Frequently, the sub-
supplier has to interpret a lot of text documents in order to find the applicable constraints for
its sub-system. Furthermore, the involved interface needs to be defined and transferred to the
sub-supplier. The product model will also partly solve this problem: the model shows the
relation to other sub-systems (i.e. to which level the design is coupled or de-coupled). This
will facilitate setting up the project’s communication platform and immediately put together
the sub-suppliers that need to solve coupled design problems. The model can also be used for
moving interfaces and optimising the scope of supply for different suppliers.

Conclusions

This paper has described a holistic approach to modelling evolving design. The model has
been used to provide a common understanding of different stakeholders involved, together
with the requirements, functions, and systems during the design of a product. Special attention
has been given to the management of different stakeholders that affect the product. The
stakeholders have been categorized as either internal or external. Furthermore, a four-step
process for defining and managing stakeholder requirements has been proposed.
The model supports the iterative and evolutionary nature between function and solution by
using a function-means structure. This co-evolution between function and form is solid
support for Value Analysis. New or optional functions (so-called "nice-to-have" functions)
can be included in the model. Adding these functions to the hierarchy will allow for the
exploration and investigation of which effects are associated with introducing the new
function. A cost-value approach has been used to evaluate existing versus new functions, and
to make sure that each new function adds more value to the product than the cost associated
with implementing it. The model will also support verification and validation, as all
stakeholders and their influence on the product is made explicit.
The proposed model is valuable support in distributed product development. It assists
in the distribution of appropriate functional and constraining requirements to each sub-
supplier. The sub-supplier will also gain information about interface and about which
stakeholders influence their system.

Acknowledgements

The Volvo Group supported this work financially through the Chalmers-Volvo donation. This
support is gratefully acknowledged. Prof. Hans Johannesson at Chalmers University of
Technology is acknowledged for fruitful discussions. The authors would also like to thank
Envirotainer Engineering, Inc. for supporting the collection of data and for valuable input
regarding the model.

References
Akao, Y., (1990). Quality Function Deployment, QFD - Integrating Customer Requirements
into Product Design. Productivity Press, Portland, USA.
Ehrlenspiel, K. and Dylla, N., (1993). Experimental Investigation of Designers Thinking -
Methods and Design Procedures, Journal of Engineering Design, 4, 201-212.
Fujita, K. and Nishikawa, T., (2001). Value-Adds Assessment Method for Product
Development Across Life Stages Through Quality Function Deployment. Proceedings
of ICED '01, Glasgow, UK.
Harding, J. A., Popplewell, K., Fung, R. Y. K. and Omar, A. R., (2001). An Intelligent
Information Framework Relating Customer Requirements and Product Characteristics.
Computers in Industry, 44, 51-65.
Isaksson, O., Fuxin, F., Jeppsson, P., Johansson, H., Katchaounov, T., Lindeblad, M., Haxue,
M., Malmqvist, J., Meshihovic, S., Sutinen, K., Svensson, D., and Törlind, P., (2000).
Trends in Product Modelling - an ENDREA Perspective. Proceedings of
Produktmodeller, Linköping, Sweden.
Nidamarthi, S., Chakrabarti, A. and Bligh, T. P., (1997). The Significance of Co-Evolving
Requirements and Solutions in the Design Process. Proceeding of ICED '97, Tampere,
Finland.
NCR (2003). http://www.metis.no/
Pouloudi, A., (1999). Aspects of the Stakeholder Concept and their Implications for
Information Systems Development. Proceedings of the 32nd Hawaii International
Conference on Systems Sciences, IEEE Computer, Maui, Hawaii.
Schachinger, P. and Johannesson, H., (2000). Computer Modelling of Design Specifications.
Journal of Engineering Design, 11, 317-329.
Sharp, H., Finkelstein, A. and Galal, G., (1999). Stakeholder Identification in the
Requirement Engineering Process. Proceedings of Database and Expert Systems
Applications, IEEE Computer Society Press, Florence, Italy.
Wallace, G. W, (1995). Balancing Conflicting Stakeholder Requirements. Journal for Quality
and Participation, 18, 84-89.