How to interconnect Product Design and Project Management including

Experience Feedback and Reusability Requirements

Citlalih GUTIERREZ1, Claude BARON1, Laurent GENESTE2,
Philippe CLERMONT2, Daniel ESTEVE3, Samuel ROCHET1.
1

LESIA, INSA, 135 av. de Rangueil, 31077 Toulouse cedex 04, France
2
LGP, ENIT, 47 avenue d'Azereix, BP 1629, 65016 Tarbes, France
3
LAAS, CNRS, 7 avenue du colonel Roche, 31077 Toulouse cedex 04, France
gutierre@insa-toulouse.fr, claude.baron@insa-toulouse.fr, laurent.geneste@enit.fr, philippe.clermont@enit.fr,
daniel.esteve@laas.fr, rochet@insa-toulouse.fr
different risk factors that can influence the satisfaction of
the objectives (costs, delays, quality) [13].
Furthermore, the system development process is
submitted to the increasing users requirements and the
evolution of technologies. Indeed, today, users require a
high level of product quality, shortened delivery delays
and an exact conformance of the product performance to
their needs. In addition, the application of the European
directive EC Directive 1999/44 in 2002 [3][9], relating
to the harmonization of the consumer protection (in
particular in terms of periods of warranty, and thus of
reliability), incites the companies to develop increasingly
reliable products. So, to be competitive, the enterprises
must do their best to satisfy these requirements while
preserving a high profitability.
Consequently, it is important to simultaneously tackle
the questions of product integration and life cycle
considerations, including quality and reliability of the
products and processes. We thus defined a methodology,
which integrates product-process-organization design
stages. This approach is presently being tested on a shared
platform interconnecting several tools exchanging joint
knowledge.
This paper first describes the philosophy of our
approach, then the tools used in the platform that supports
it. A second part presents the methodology used to
manipulate the information exchanged between design,
decision support and experience feedback tools. The
paper finally concludes with the results obtained in this
research work and exposes our perspectives.

Abstract:
Nowadays, the development of high quality and high
performance products, with short time to market,
represents a challenge for manufacturers. So, they must
take into account, in the early steps of the product
development, constraints that usually appear during the
project management process. In this article, we define a
process, based on the reuse of technical and nontechnical knowledge and experience feedback, that
improves the communication between the design and the
project management teams, in order to facilitate the
emergence of collective solutions. After a brief
presentation of the research objectives, this paper tackles
the problem to closely connect design and management
and suggests a methodology to associate the project tasks
with the functionalities that the product has to implement.
Keywords:
Product/system design, project management, product and
process integration, experience, reuse, decision support.

1. Introduction
With the intensifying competition in industry, product
design and development is becoming vital to the
prosperity or even survival of companies. Product design
and development are complex tasks involving more and
more disciplines, such as management, prototyping and
organization. Product design implies the definition of a
project, the identification of the technologies to be used,
the establishment of a schedule, an evaluation of the load,
communicating with the clients [8] and the project teams,
managing the risks and the speculations, insuring the
product quality and reliability, etc. All these tasks and a
lot more must be achieved during the design, and
controlling the development process on both the technical
and the management sides constitutes a tricky issue.
On the one hand, the product design process is a wellknown procedure composed of several successive stages
of functional and technological definitions in order to
obtain a decomposition of the product into modules,
reusable ones if possible, thus preparing the virtual
prototyping. On the other hand, project management is a
difficult process to lead since it may be disturbed by very
0-7803-9093-8/05/$20.00 2005 IEEE.

2. The project objectives

Our main objective is to integrate the design of
innovative systems with project management by means of
shared knowledge coupled with an experience feedback
strategy. For that, we imagined a methodology that
enables to capitalize, to visualize and to reuse all the
information exchanged during the development process.

2.1. The 'Shared' approach

The originality of this research is to associate the
processes of Product Design and Project Management
during the early steps of "top-down design" and "tasks

294

between several possibilities to conduct his project (the

scenarios). This is implemented thanks to a decision
support methodology based on evolutionary computing
[2].
This work is conducted by several collaborating
research teams from the LAAS-CNRS, the LESIA-INSA
and the LGP-ENIT laboratories. An important point of
this work consists in the connections we tried to develop
between different tools engaged in the project in order to
build an experimental shared platform. This platform will
be described here below.

definition" (see Figure 1). Indeed, on the product design

side, the identification of the technical options for the
product (performance, reliability), participates in the
definition of the tasks on the design project side, which
also adds its own constraints (costs, delays, suppliers...)
[15]. We thus built a 'shared' model which integrates the
constraints coming from both Product Design and Project
Management processes and from which it is possible to
determine an optimal schedule to organize the project,
called 'scenario'.
Our ambition thus is to connect these processes, from
a conceptual and methodological point of view, but also
from an operational point of view with the definition of
appropriate tools. For this study, we propose to work with
a 'shared' knowledge representation, modeled within a
database from which each actor of the project can extract
useful information (see Figure 1). This way, the project
manager can have an integrated point of view on all the
system parameters and thus, analyze the whole set of
technical and economical consequences of an
organizational or technological choice to take the best
possible decision at any time to lead the project.

2.2 The platform tools

Following a prototyping approach, several methods
and tools, individually developed by each research
partners, are being connected into a shared platform, in
order to integrate both design and management processes.
The following tools are used:
UML, for the textual specifications translation towards
HiLeS,
HiLeS [11], a tool based on the SART formalism to
describe the functional architecture of a product at a
system level using interconnected and timed blocks.
From this model, it is possible to obtain a virtual
prototype of the product thanks to VHDL/AMS
simulation,
TINA [5], a validation tool based on Petri nets to verify
the design defined in HiLeS,
GESOS [2], which makes the selection of the best
project scenarios,
LORA [7], to precisely schedule the selected scenarios.
The targeted platform should rely on shared data that
tools could access and exchange, to ensure their
interoperability.
A first database architecture, inspired from the eXist
XML database, an open source product, is thus being
studied to allow all these tools to communicate. To take
the experience feedback process into account in the
project (to avoid a repetition of previous errors, to provide
the decision maker with lesson learned, etc.), this
database must also integrate principles extracted from a
generic tool, TREX [14], such as a classical search based
on keywords or a more difficult search based on analogies
using case based reasoning techniques.
With these tools, we plan to connect design and
management processes by the use of the following
methodology:
1. Initially, the textual specifications are formalized by
separating technical requirements and project constraints.
The formalized data will be used during the project for
semi-automatic validations of the choices. These
requirements can represent objectives (product
performances, low assembly cost) or constraints
(limited resources, delays).
2. Then, the HiLeS tool enables representing the various
functional architectures of products which respect

Figure 1 Strategy to connect Product Design and Project

Management
This allows the traceability in the development and
management processes, which is necessary to find and
follow the component characteristics from its design till
its delivery, through the manufacturing steps, but requires
the definition of joint information models. In this method,
we introduce the capitalization and re-use strategies of
knowledge and know-how into design and management
processes.
This methodology is principally dedicated to industrial
complex systems design projects where the project leader
must coordinate the information from the functional
analysis of the system until the organization of the actors
and resources to design it, through the intermediate study
of the system physical architecture. We are more
particularly interested in projects which realization is not
distributed on several places (we did not manage the
logistic aspects). Moreover, this work takes place in the
preliminary phase of top-down design, i.e. before the
effective beginning of the project.
Finally this process leads to the selection and
optimization steps where the manager makes his choice

295

description of the main functions of the system

represented with structural and functional blocks, at level
2, a description of complementary functions that are not
specified in the original specifications but that are
necessary to realize the main function, also represented by
blocks; the last level, level 3, exposes the details of
elementary functions and Petri nets introduced for the
temporal management of the events that appear in level 2.

technical constraints. After this step, the functional

architectures are manipulated in order to build physical
architectures of products (for additional information about
this operation see [3]). At this stage, a second verification
of the model coherence regarding the initial technical
constraints is processed. Several possible product
structures able to respect the technical constraints are
obtained at this stage.
3. Considering these different architectures, the project
team proceeds to the various call for tenders that will be
used as a basis to elaborate a panel of possible
organizations for the project.
4. On this basis, we can construct several possibilities to
conduct the project, called 'scenarios', each one respecting
the project constraints, and between which a tricky choice
has to be made. At this stage, our objective is to provide
the decision maker with a reduced set of projects
scenarios from which he will be able to make this choice.
Figure 1 illustrates this procedure. Each tool
participates to the platform with its specific role. Sharing
knowledge is essential to have a joint vision. This paper
now focuses on the contributions of HiLeS, GESOS and
TREX tools, since HiLeS generates the product functional
knowledge (performance, reliability, etc.), which is
completed with non-functional knowledge (cost, delays,
etc.) [1], this knowledge being capitalized with TREX,
and exploited by GESOS, to select the 'best' scenarios to
lead the project among the different possibilities.

Figure 2 HiLeS Decomposition

The use of HiLeS enables to obtaining a coherent
representation of system, which is validated thanks to
tools built on Petri nets like TINA [5].
Our first contribution is to visualize the HiLeS
decomposition stage with a functional representation: it is
a schematic, hierarchical and tree-based view which we
called 'HiLeS Functional Representation'. It represents the
different hierarchical levels of decomposition made in
HiLeS and facilitates the visualization and the analysis of
the system.
This functional representation has a very important
role because it initially offers a list of all elementary
functions of the system, hierarchically organized.
Moreover, this representation will lead to defining a range
of several possible representations of components ('HiLeS
architectures') respecting the initial system requirements.
In other words, with specifications and the top-down
design step results, the designer can propose several
solutions for the system implementation, described below.

3. The management of innovative and

reusable systems
Our design platform is composed of inter-operable and
complementary tools that enable to connect both product
design and project management processes. At the highest
level, the client requirements must be translated into
functional and non-functional objectives. Our purpose is
now to explain how the information is exchanged between
tools through the whole previously described process.

3.1 HiLeS

3.2 The functions aggregation into the HiLeS

Architectural Representation

HiLeS is a high-level specifications tool; it offers a

language and formalism for top-down design [10]. This
tool formalizes the textual specifications of a system by a
graphic representation, which can be simulated.
HiLeS works with basic components, which constitute
the formalism. Using them, the project designer can
associate a hierarchical structure with Petri nets to make a
high level description of systems. Figure 2 exposes this
procedure. Levels of the top-down design under HiLeS
must correspond to the levels of hierarchical
decomposition into several levels of abstraction of the
project. This allows visualizing the system more finely
through its various components.
The HiLeS decomposition, as it appears in the
example of Figure 2, allows, at level 0, to obtain a
description of the system environment, at level 1, a

The top-down design leads to a clear and complete

specification of each elementary function of a HiLeS
functional representation of a system. This functional
representation has been verified through a TINA
procedure. The next step is to recompose this
representation into an architectural representation of
components corresponding to external supplies already
existing and/or innovative ones: this is called
partitioning. To conduct this partitioning, the designer
has to take into account a lot of functional and non
functional parameters such as: external supply (existing
offer), re-use of internal how-know (reusability of
components and experience feedback), existing
agreements with specific suppliers, delays and costs, etc.

296

limited set of scenarios in order to offer a reduced

numbered of the 'best' solutions.

At this stage of development, this decision procedure

is completely manual and we are working on the
definition of influent parameters and possible criteria to
support the decision, in the perspective of reusable
components.
This procedure, applied on the design side, also make
the connection with the management side: it thus ends
with the definition of a set of correlated project tasks
according to the potential supplies identified. This
mechanism is called 'functions aggregation' and directly
leads to obtaining a HiLeS Architectural Representation
of the system, as shown in Figure 3.

Figure 4 Components and tasks partitioning

Figure 4 schematically shows the method of
components and tasks partitioning and indicates where
interactions are envisaged between the design and
management processes and the shared database. Let us
now point out the importance of the experience feedback
process in our methodology.
We have tested our approach on an industrial example
of control of a nuclear power plant using sensors
detecting the deformations on walls in the reactor, [12]
details this case study. The results obtained were
satisfying and encouraged us to envisage a stronger
integration of experience feedback.

Figure 3 From Functional to Architectural system

representation

3.3 From HiLeS functions to project tasks

At this stage, the designer possesses different
information acquired during the previous phases, so he
can begin to consider a possible work organization. The
first step consists in defining the tasks to reach the project
objectives and scheduling them, determining delays,
costs, identifying potential suppliers, estimating needed
machines and manpower, etc., for each component that
the design side identified. A possible connection of
functions with tasks could be to define as many tasks as
possibilities exist to achieve the function, considering the
supplies (buy, make, adapt).

3.5 The experience feedback

In order to face quick variations of the environment,
the dynamics of evolution of industrial companies
(organizational changes, people mobility and so on) has
considerably increased. Therefore, the capitalization of
past experiences and the ability to inject the lesson
learned into operational industrial processes has become a
strategic issue. The "Experience Feedback" may be
considered as a structured approach for capitalization and
exploitation of knowledge obtained in past success and
failures.
Since the eighties, many firms have understood the
importance of Experience Feedback. They developed
different methods, techniques and tools to support
complete processes especially in the field of
dependability. More recently, the Experience Feedback
has became a challenging research topic (see for instance
[6],[1],[4]) and its scope has broaden not only to the
whole set of information produced during the life cycle of
a product but also to the training and skill improvement of
employees.
In the context of connecting product design and
project management it is natural to implement experience
feedback processes in order to improve both design and
project management activities.
The triggering point of an Experience Feedback
process is the occurrence of an unexpected situation

3.4 The design and task partitioning

From the requirements, through the specifications, and
following a top-down design process, the partitioning
procedure, applied to design components and
management tasks, is led in order to decompose the
system into reusable physical components on the one side,
and into reusable project tasks on the other side. All these
information are stored into a shared database so that
finally both designer and manager can respectively define
some possible architectures for the product and some
possible organizations for the project.
The partitioning process is supported by the HiLeS
tool and uses the TREX and know-how mechanisms; it
consists in a hierarchical decomposition and leads to
obtaining a set of components envisaged to build the
system, which will be associated to specific tasks for the
final product development.
From these tasks will be generated the project
scenarios, each scenario representing a coherent chaining
of tasks and thus defining a possible schedule. Then, the
GESOS tool makes the selection and optimization of a

297

called TREX [14]. This tool, based on an Excel sorter,

provides a framework to the actors at the time of the
resolution and makes it possible to capitalize in a no
intrusive way information, experiences and rules
employed and/or created. The tool was implemented in a
company of the railway sector.
Our suggestion regarding the general design procedure
is thus to integrate reusable component and experience
feedback in the criteria of partitioning.
A last step, to achieve the whole process from HiLeS
function to a schedule of the project tasks, is to help the
project manager to define an optimized organization for
the design project in order to reach the targets. This is
provided by an efficient decision support methodology,
based on genetic algorithms, as described here below.

(called an event) encountered during the life cycle of a

product or of a project. Since the event reveals an
unexpected situation, as soon as it is detected, a problem
resolution process is launched. This process corresponds
to a sequence of activities generally defined as a standard
workflow that leads, in the best cases, to the resolution of
the problem that caused the event. The problem solving
process often involves several experts and during this
process, it is important to capitalize the progress and
results of the expertise (this is what is called an
experience). Each activity of the problem resolution
process feeds the Experience Feedback database with
Experience Feedback records that contain the expert
analysis produced during the activity. This structure
enables to define a network of product/project expertise
which nodes are the Experience Feedback records.
When the solving process is achieved, it is judicious to
build rules that will be systematically applied in future
similar product developments. Theses rules constitute a
generalization and a reinforcing of a set of experiments.
The elaboration of such rules generally involves one or
several experts who, according to a set of previous
experiments, can propose rules in order to incorporate
them into the operational industrial processes. This allows
actors of these processes to avoid a path that will probably
lead to a problem (preventive aspect).
When a set of experiences and rules is formalized and
memorized, it is important to facilitate the exploitation of
this technical patrimony by the actors of the company. Let
us notice that the users may be involved in the Experience
Feedback process itself but also in any other operational
process (design, fabrication, validation, purchase...).
For the consultation of the experience database, we
propose the set up of a search to exploit the information
contained in the experiments database in order to prevent
a past error to be made again. So, after a search in the
database, the user is informed if the current state of his
work includes elements that have already been
problematic or elements that are similar to past
problematic elements. Case based reasoning mechanisms
seem to be very suitable to help this exploitation task and
a study is under way to develop tools of this kind.
Two key elements for a rational and successful
integration of an Experience Feedback process into
existing processes are generally not taken into account:
1. A framework for modeling the interaction between
processes, actor skills and information system and a
methodology of implementation of a decision support
system are necessary in order to facilitate the set-up
of an Experience Feedback process.
2. Advanced knowledge acquisition, management and
exploitation tools, especially for the search of past
similar situations and adaptation mechanisms for
solving problems that occur during processes.
These concepts were implemented in a dataprocessing tool dedicated to the problems resolution,

3.6 The decision support methodology

As said in 3.4, to predict an initial organization for a
project and then to lead the project, the project manager
has to select an organization among the valid ones
obtained by combining project tasks in an optimal
schedule to reach the product targets in terms of costs,
duration, quality, etc. This constitutes a tricky operation,
because many options, defined during the design, can be
associated to each task of the project. Choosing and
optimizing a scenario for the project progress in order to
reach the project target as closely as possible thus results
in a combinatorial problem that only a heuristic method
can solve.
Moreover, as mentioned above in 3.5, when an
unexpected event occurs during the project, or when a
major deviation occurs from the initially envisaged
organization of activities, it seems important that the
choice of a new working plan is being guided by its
coherence. This plan should be coherent from a technical
point of view, with regard to the design options already
taken, also from a project point of view, with regard to the
management choices made before. In this context, the
project manager has to first identify a set of possible
alternate scenarios to lead the project. Then, among these,
he has to select one or several ones, which will allow him
to reach the project technical and non-technical targets as
closely as possible. He finally has, to organize his project,
to arbitrate among solutions on which he often has not
enough visibility, because they are generally dependent
on design decisions. In this context, our first objective is
thus to help the project manager to define, follow and
adapt a coherent organization of the project activities.
This essentially relies on two actions: favoring the
coordination of the project manager with the technical
design team and assisting the decision that the project
manager has to make between several possible project
organizations. Our second objective is to make the
management process robust and adaptive in case of
external technical, social or economical hazards, in order
to keep respecting the fixed project targets as exactly as

298

possible. However, selecting a limited set of best

scenarios among thousands of scenarios is a large-scale
combinatorial problem.
This problem can be considered as a multicriteria
problem of distances minimization between the
performances reached by the scenario (in terms of costs,
delays, quality, risk associated to the project) and the
fixed targets. In such types of problems, it is important, to
find a solution, to examine all possible combinations of
decisions and variables. Consequently, no partial
enumeration based exact algorithm could consistently
solve them, because of the slow convergence rate. Indeed,
by exploiting problem specific characteristics, classical
heuristic methods, with a relatively limited exploration of
the search space, produce acceptable quality solutions in
modest computing times. We thus experimented, to make
this selection of scenarios, the use of genetic algorithms to
help the decision-maker. The GESOS tool has been
developed and integrated into the platform. After several
case studies, we obtained encouraging results [3]. We are
now testing our methodology and framework on industrial
cases.

Carlos Hamon and Hernn Duarte, for their valuables

comments on this research work.

4. Perspectives and Conclusions

[6] Bickford C. J., "Sharing lessons learned in the Department

of Energy", Intelligent Lessons Learned Systems
Workshop, Austin, Texas, 2000.

6. References
[1] Aha D. W., Weber R., Muoz-Avila H., Breslow L. A. &
Moy Gupta K., "Bridging the Lesson Distribution Gap",
Seattle, Wash., USA, 4-10 August, 2001.
[2] Baron C., Esteve D. &. Rochet S., "How evolutionary
computation can be introduced to select and optimize
scenario along a product design process", Transaction on
sys., V-3, C-2, pp. 888-893, ISSN 1109-2777, April 2004.
[3] Baron C., Rochet S. & Gutirrez C., "Proposition of a
methodology for the management of innovative design
projects", 5th annual International Symposium of the
International Council on Systems Engineering, July 2005.
[4] Bergmann R., "Experience Management: Foundations,
Development
Methodology
and
Internet
Based
Applications", Springer-Verlag, 2002.
[5] Berthomieu B., Ribet P. & Vernadat F., "The tool TINA Construction of Abstract State Spaces for Petri Nets and
Time Petri Nets", International Journal of Production
Research, vol. 42, No 4, July 2004.

In order to answer the obvious need to simultaneously

tackle the questions of product integration and life cycle,
we defined an approach, which integrates productprocess-organization design stages, and experimented it
on a shared platform composed with several connected
tools and based on shared data including experience
feedback.
This paper first described the shared model approach,
then the tools used in platform that supports it, and finally
explained the methodology to manipulate the information
exchanged between the design, decision support and
Experience feedback tools. Tools are integrated from a
global point of view in the management of knowledge for
the reutilization, in particular by the capitalization of
project decision process. The key point for interpreting
reusable know is in the partitioning criteria. At this stage,
the procedure is completely manual but our ambition is to
propose a methodology to support the decision process.
This research work optimizes and selects the information
of the product design and project management processes,
where our principal interest is to obtain systems of quality
from reusable components. The main interest of this study
is to consider all main functional and non-functional
aspects to design systems of quality and high
performance. However, it is still necessary to better
formalize the methodology and to test it with real
industrial case studies.

[7] C. Briand, P. Esquirol, "Task Charts: a time model for the

specification of alternative processes", LAAS Report
01057, Toulouse France, 2003.
[8] Cros T, "Matriser les projets avec lextrme programming
pilotage par les tests client", Cpadus-ditions, 2004.
[9] EC Directive 1999/44 of 25 May 1999 of the European
Parliament and the Council on certain aspects of the sale of
consumer goods and associated guarantees, 1999, L 171/12.
[10] Hamon J. C., "Mthodes et outils de la design amont pour
les systmes et microsystmes", thse de doctorat, LAASCNRS, Toulouse, France, March 2005.
[11] Hamon J.C., Esteve D. & Pampagnin P., "HiLeS Designer:
a tool for systems design", LAAS, Toulouse France, 2003.
[12] Maurice R., "Mthodologie de conception pour la
ralisation d'un microsystme multicapteurs autonome
communicant", Rapport LAAS No04273 7th Journes
Nationales du Rseau Doctoral de Microlectronique,
Marseille (France), May 2004, pp.166-168.
[13] Miana M., "Conduite de projet, vol. 2 : les outils de
l'exploitation du planning et de la matrise des dlais",
1998.
[14] Rakoto H., Hermosillo Worley J. & Ruet M. "Integration of
Experience Based Decision Support in Industrial
Processes", 2002 IEEE Int. Conf. on Systems, Man &
Cybernetics Hammamet, Tunisie, October 2002.

5. Acknowledgment

[15] Yacoub M., "Design des systmes : calculs technicoconomiques et aide la dcision dans la conduite d'un
projet recherche", Report No04329, Toulouse, July 2004.

We would like to acknowledge our research and

industrial partners, and those who contributed to the
creation and revision of this paper. We also thank Juan

299