Memory Meetings
An Approach to Keep Track of Project Knowledge in Design
Nada Matta and Guillaume Ducellier
Université de Technologie de Troyes 12 rue Marie Curie, BP 2060, 10010 Troyes Cedex, France
Keywords: Knowledge Management, Project Memory, Traceability, Design Project.
Abstract: Design projects are cooperative activities in which several actors from several fields work together in order
to rich a goal. The challenge is how to keep track of knowledge from daily work in this type of activity.
Projects documents are not sufficient to be analysed to extract this type of knowledge. This paper presents
techniques to acquire and represent knowledge from design projects. A specific approach has been
developed in order to keep track of meetings and to link design rationale to organizations elements and to
results of a project. This approach has been integrated to designers’ environment using Product Life Cycle
Tool.
1 INTRODUCTION
To enhance learning in an organization, the
knowledge modelling has to emphasize the know
what and know how (Colin, 1998); (Nonaka et al.,
1995). “The learning content is context specific, and
it implies discovery of what is to be done when and
how according to the specific organizations
routines” (Easterby-Smith et al., 2007). So, the
context in which the knowledge is produced has to
be also represented as same as knowledge “knowing
what” and “knowing about”. For instance,
representing ontology tends to emphasize not only
concepts but also documents source of these
concepts (Guarino, 1998). However, sharing
documents, information and experiment without
structuring of this information and feedback analysis
as used currently on social network as support of
knowledge sharing, is not sufficient to enhance
learning. In fact, the how is shared but not the what.
Behavior laws provide strong semantics to
emphasize reason of expert’s behavior, ready to be
reproduced to solve new problems.
In our work, we aim at representing the
“knowing what” and “knowing about” of a
cooperative activity. In other terms, we tend to
emphasize knowledge produced in a cooperative
activity (design projects) and its context. We
propose then to focus on what is debated during
cooperative activities rather than on knowledge
management methods, which mostly tend to define
the “common ground”.
The challenge is how to extract knowledge from
a project organization that is a virtual one. In fact,
project organization is defined at the beginning of
the project and dissolved at the end. Actors of this
type of organization are belonging to different
companies. Otherwise, project documents are not
sufficient as sources to extract project knowledge
and especially collaborative decision-making.
We propose in this paper an approach to keep
track and structure knowledge produced during
design project realization, using designers’
workspace.
2 HOW TO REPRESENT
COOEPRATIVE ACTIVITY
KNOWLEDGE?
We distinguish knowledge related to a given field or
business from knowledge related to cooperation:
- The nature of knowledge is different: The
business knowledge is related to a field and contains
routines and strategies developed individually from
experiences, which involve a number of
experiments. The cooperative knowledge is related
to several fields, i.e. several teams (of several
companies) and in several disciplines collaborates to
carry out a project. So there is a collective and
organizational dimension to consider in cooperative
336
Matta N. and Ducellier G..
Memory Meetings - An Approach to Keep Track of Project Knowledge in Design.
DOI: 10.5220/0004541203360343
In Proceedings of the International Conference on Knowledge Discovery and Information Retrieval and the International Conference on Knowledge
Management and Information Sharing (KMIS-2013), pages 336-343
ISBN: 978-989-8565-75-4
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
knowledge. Representing domain knowledge
consists in representing the problem solving
(concepts and strategies) (Castillo et al, 2005). On
the contrary, emphasizing knowledge in cooperative
activity aims at showing organization, negotiation
and cooperative decision-making (Djaiz et al, 2006).
Otherwise, knowledge observed in a corporative
constitutes one experiment to be structured.
- Capturing of knowledge is different: The
realization of a project in a company implies several
actors, if not also other groups and companies. For
example, in concurrent engineering, several teams of
several companies and in several disciplines
collaborate to carry out a project of design. The
several teams are regarded as Co-partners who share
the decision-makings during the realization of the
project. This type of organization is in general
dissolved at the end of the project (Matta et al,
2000). In this type of organization, the knowledge
produced during the realization of the project has a
collective dimension, which is in general volatile.
The documents produced in a project are not
sufficient to keep track of this knowledge. In most of
the cases, even the project manager cannot explain it
accurately. This dynamic character of knowledge is
due to the cooperative problem solving where
various ideas are confronted to build a solution. So
acquisition of knowledge by interviewing experts or
from documents is not sufficient to show different
aspects of the projects and specially negotiation
(Bekhti et al., 2003). Traceability and direct
knowledge capturing are needed to acquire
knowledge from this type of organization.
Based on this distinction, we propose to study PLM
platforms for identifying what is and what should be
for enabling cooperative knowledge and project
memory.
3 PROJECT KWNOLEDGE
REPRESENTATION
A project memory describes "the history of a project
and the experience gained during the realization of a
project". It must consider mainly (0):
The project organization: different participants,
their competences, their organization in sub-
teams, the tasks, which are assigned to each
participant, etc.
The reference frames (rules, methods, laws ...)
used in the various stages of the project.
The realization of the project: the potential
problem solving, the evaluation of the solutions
as well as the management of the incidents met.
The decision making process: the negotiation
strategy, which guides the making of the
decisions as well as the results of the decisions.
Figure 1: Project memory.
Often, there are interdependent relations among
the various elements of a project memory. Through
the analysis of these relations, it is possible to make
explicit and relevance of the knowledge used in the
realization of the project. The traceability of this
type of memory can be guided by design rationale
studies (Karsenty, 1996) and by knowledge
engineering techniques (Matta et al, 2000).
3.1 Decision-making Representation
Several methods were defined to represent the
design rationale in a project. These methods can be
classified in two principal categories: the decision-
making driven representation and the dynamic of
problem solving representation.
3.1.1 Decision-making Driven
Representation
In this type of approach, the design rationale, also
named the analysis of the Space of design
(Buchingham Shum, 2005) is represented through
the elements that influenced a decision-making. We
can distinguish primarily the methods IBIS (Dieng et
al., 1998), and QOC (Maclean et al., 1991),
(Buchingham Shum, 2005).
The space of design is generally represented in
these methods by design choices. These choices are
structured like answers to the questions evoked by
the design's problem. Arguments can justify the
choices of an option according to a given criteria.
The options generate other questions to which the
designers answer by options.
MemoryMeetings-AnApproachtoKeepTrackofProjectKnowledgeinDesign
337
3.1.2 Representation of the Dynamics of
Problems Solving
Some approaches offer a more global representation
of the design rationale. Indeed, some elements of the
context like the activity of the organization, the role
of the actors and the artifact are represented. We can
distinguish especially, the DRCS system (Klein,
1993). It offers several views on a project: modules
of the artifact, association of the tasks, evaluation of
the specifications, decision-making, alternatives of
design and argumentation. Some models are also
defined in order to emphasize dynamic problem
solving. We note especially the DIPA model
(Lewkowicz et al., 2002). This model takes into
account the transformation of problem definition and
constraints into propositions, argumentation and
solutions.
3.1.3 Discussion
A project memory must contain elements of the
experience coming as well as from the context and
from the problem solving. Context is important to
enhance learning in an organization (Easterby-Smith
et al., 2007). There is a strong mutual influence
between context and solutions. So that if the context
is omitted the restitution of problems solving is
insufficient.
We often observe this type of phenomena in the
results obtained with the approaches quoted above.
Except the system DRCS, some approaches do not
define techniques to represent this influence between
the context and problems solving in a project. Even
DRCS system only enables the partial representation
of this context (the tasks organization and the
projection of the decisions on the artifact). In the
same way, we can observe some efforts in DIPA
formalism to represent the organization of work in a
workflow (task/role). However, other elements have
to be identified like constraints, directives, resources
and competences, etc. We consider in our approach
representing a more complete vision of the project
context by emphasizing its influence on the
problems solving.
However, the representation of the problems
solving as it is suggested by the approaches noted
above remains incomplete as a representation of the
space of negotiation between the project actors.
Indeed, the first type of approaches rather allows a
representation driven by the decision in order to
show only the elements that influenced a decision. In
the second type of approaches, an effort is made to
represent the dynamics of the decision-making.
However, a negotiation is a space of discussion
between several actors where various objectives are
confronted, alliances and conflicts are constituted. In
the same way, a negotiation has a history and is
influenced by the alliances and the decisions made
during the last negotiations. Our approach allows
users keeping in memory this dynamics of
negotiation so that its restitution is easy to show the
various elements included in problem solving. We
define first a project memory structure that allows
representing several concepts that will be consider in
project memory and their mutual influence.
3.2 Representing Structure of a Project
Memory
As we noted above, project memory has to consider
from one side, several dimensions like: organization,
problem context and definition, negotiation and
cooperative decision-making and from the other
side, semantic and cognitive representation like:
“know what” and “know how” (Colin, 1998). In
fact, to enhance learning from project organization,
it is necessary to emphasize how and when activities
are conducted and also what and why these activities
are conducted (Easterby-Smith, 2007). We consider
these two aspects in a structure to represent a project
memory. The organization description (how and
when) can be directly traced from design activity
(0). We find this information in design environment
and tools: documents, discussions, process, product,
etc.
Figure 2: Concepts to represent in a Project memory.
Representing of the semantic aspect of project
organization needs analysis and abstraction. Most
knowledge management methods focus on the
definition of the “common ground”. In our approach,
the relation between cooperative decision-making
and elements in project organizations are emphasis
and are the central point of our proposition. The
interest is then to structure the project memory
(Bekhti et al., 2003). Mainly emphasizing the
characteristics of suggestions and decision can do
KMIS2013-InternationalConferenceonKnowledgeManagementandInformationSharing
338
this relation, using criteria. We use the DYPKM
approach (Bekhti et al., 2003) to extract criteria from
decision-making meetings and to define links
between criteria and project elements.
Example of such links are shown in (0). This
example are extracted from a project that aims at
proposing a number of principles that can guide
companies to evaluate their risk in their activities
(Bekhti et al., 2003).
Figure 3: Links between criteria/decision and solution
emphasize why of product evolution and the final solution.
For instance, to solve the problem about Risk evaluation
actors decide to define an Engagement principle. We show
how they decide that by representing the main criteria of
the decision: “Adequation, Validity and Clarity”.
DYPKM approach recommends keeping track of
design rationale from the project context and
decision meetings. Traceability of decision-making
has to be done on two steps taking notes during the
meetings and structuring notes to define report.
Secretary in a meeting has to take notes of
discussions in order to keep track of links between
these discussions, questions and participants. When
writing report, he/she has to distinguish suggestions
from arguments and to annotate them by criteria.
Example of such links are shown in (0).
Figure 4: Meeting Report structure using DYPKM (Bekhti
et al., 2003). This structure shows mainly relations
between question, propositions of solutions and arguments
(red text). Criteria (as notes in links) sum up main
characteristics of propositions and arguments.
In order to obtain this type of results and to
integrate traceability during an activity, we define a
tool (Memory Meeting) that supports collaborative
decision-making traceability. Results are then linked
to other project parts using designers’ tools like
Product Life cycle management tools (PLM).
4 MEMORY MEETINGS
The principle of our work is to structure a meeting
result on questions, suggestions, arguments and
criteria. Links to participants who enunciate
suggestions and arguments must be also recorded.
Based on first tests of DYPKM (Bekhti et al, 2003)
on real applications, we identify that secretary
cannot take notes and structure them as the same
time. So, we propose on our approach:
First, secretary can take notes during the
meeting, showing questions, discussions,
participants and decisions
Second, when he/she makes the meeting report,
he/she should identify suggestions, arguments
from discussions and define criteria. In general,
in projects, head of projects does generating
reports. Elsewhere, distinction between
suggestions, arguments and identifying criteria
will be done by the project responsible.
In order to integrate collaborative decision-making
traceability in the project activity, we use mobile
equipment, like smartphone and organizer as support
of our tool. Nowadays, a lot of people have a
smartphone, so, we develop an application on an
IPhone that help to record and take notes during the
meeting. This application builds links between
questions, discussions and participants. Questions
can be extracted from the schedule of the meetings,
in the same way, participants can be added from the
meeting organization.
Figure 5: Prepare meeting using Memory Meetings.
MemoryMeetings-AnApproachtoKeepTrackofProjectKnowledgeinDesign
339
This information can be directly obtained from
project management tool through an XML file.
Secretary also can directly put information about
meetings in the Memory Meeting application (0).
4.1 Memory Meetings Record
During the meeting, secretary, can select the
question to be discussed, select participant who
speak and record and take notes at the same time.
(0).
Figure 6: Discussions record linked to participant and
question.
So, notes and record are linked directly to the
selected question and participant. He/she can select
easily another participant, or another question.
Results of the meetings can be directly extracted
as XML file and/or used later to define the meeting
report.
4.2 Memory Meetings Report
Secretary uses Memory Meetings application to
define a report. Our aim on traceability is to keep
track not only link between question, discussions
and participants but also to structure discussions in
order to identify suggestions, arguments. The QOC
(Maclean et al, 1991), approach shows that
identifying criteria is important. They put on the
main characteristics of discussions. We show in
Figure 3, how criteria are important to index the
evolution of the design. We define a set of criteria
based of an analysis of design problems (Matta et al,
2000). Criteria can concern the proposition and the
project strategy (0).
Figure 7: Design project problems (Matta et al., 2000).
So project responsible can directly annotate
discussions by criteria using Memory Meetings
application (0). Criteria can be also modified related
to project type. We guess that small interface of
Smartphone is not easy to use for this activity. So,
Memory Meetings is also available on Ipad.
Figure 8: Identifying arguments, Suggestions and
annotating them by criteria using Memory meetings
application. Project responsible can read and modify notes
and hear record related to each question and participant.
He has to annotate related notes by a criteria and the
discussion type (suggestion, arguments, decision, etc.).
The result of this work is under two aspects: a
XML file, which will be integrated in project
management tool, and a MsWord Report (0).
KMIS2013-InternationalConferenceonKnowledgeManagementandInformationSharing
340
Figure 9: Example of Generated Report from Memory
Meetings Report. We note discussion structuring:
Question, Participant, criteria (red text) and discussion
type (blue text).
5 INTEGRATE
DECISION-MAKING
TRACEABILITY IN PLM
A product Life cycle Management is defined as “a
strategic business approach that applies a consistent
set of business solutions in support of the
collaborative creation, management, dissemination,
and use of product definition information across the
extended enterprise from concept to end of life -
integrating people, processes, business systems, and
information.» «PLM holds the promise of
seamlessly integrating and making available all of
the information produced throughout all phases of a
product’s life cycle to everyone in an organization,
along with key suppliers and customers.» (Sudarsan
et al., 2005). So, a PLM platform allows managing
the product data along its life cycle process:
specification, design and manufacturing and requires
efficient traceability functionalities, often based on
the definition of standards (Ducellier et al., 2006).
In a PLM, The product development is
represented as a decomposition of objects. Each
object is described by its parts (components),
description documents (specifications, propositions,
etc.) and dynamic documents (CAD, etc.). For each
part’s problem, a report (if needed) is defined by the
designer. A Modification workflow is then generated
corresponding to the problem report (0). This
workflow is decomposed by decision-making and
modification phases (Matta et al., 2011). The impact
of the problem is calculated and related project
members are asked to decide about the modifications
and considering its impact. Meeting and/or using a
vote system can do decision-making. When the
decision is made, modifications can be performed to
the part.
Figure 10: Product representation in a PLM.
When a problem generates a modification
workflow, we have an access to members that will
contribute to the decision. The decision is
represented in a report. So, the result of Memory
Meetings can be directly integrated as a modification
decision related to the concerned part. The XML file
result of memory Meetings report, is then treated in
order to integrate links between decisions,
participant, suggestions, arguments and question (the
problem part) as a modification report. Related
criteria is directly linked to product modifications
(0).
Figure 11: The characteristics annotation of the product
evolution.
0 shows an example of the integration of criteria
in the design cycle of a “PHILIPS Camera” using
Windchill, a PLM tool developed by PTC
(www.ptc.com): specifications of the front of the
camera: buttons, display, etc.
This criteria annotation provides a first structure
of the product evolution. Based on that and using
links between project elements, we can extract
several views about the design of the product. For
example, the reason of a result based on the project
organization: members’ profile and roles and tasks,
why such result for this requirement, etc.
In Windchill, there is no representation of the
evolution of tasks. In fact, tasks are represented in a
MemoryMeetings-AnApproachtoKeepTrackofProjectKnowledgeinDesign
341
planning and linked to members and objects. But the
evolution of the planning is not enhanced in
Windchill. In order to respect our project memory
structure we plan some changing in the PLM in
order to handle as same the evolution of the project
as the product. In the same way, we have to keep a
structured track of this evolution. So, as we
proposed a structuring of the product using
characteristics, criteria will be also used to
characterize decisions on tasks and project members.
Figure 12: Example in Windchill: specifications of the
front of a “PHILIPS” Camera. We note that the reasons of
modifications are showed: dimensions, Behaviour and
Interaction problems, quality requirement, etc.
6 CONCLUSIONS
Knowledge management techniques to handle a
cooperative activity are not the same as individual
one. Knowledge in cooperative activity is related to
organizational dimensions as coordination,
competences, roles and negotiation. Individual
activity produces professional knowledge explained
by tasks and concepts. Making explicit of
knowledge in cooperative activity cannot use the
same approaches (CommonKADS (Shreiber et al.,
1995), MASK (Matta et al., 2001) recommended in
profession KM, due to the virtually cooperative
activity organizations.
We propose in this paper to study a KM
approach in design project, which are a type of a
cooperative activity. This approach recommends
traceability and continuous knowledge structuring
which has to be integrated in the actors’ workspace.
From one side, we define Memory Meetings
application in order to keep track of decision-making
from meetings and in another side; we integrate
traceability in designers’ workspace using PLM.
First tests are done in order to check the
feasibility of our approach, but, we have to extend
tests in order to validate traceability in real project
organizations. For that, we work with a company
(PI3C) that loan PLM services.
We also aim at integrating project memory in
other project management tool and other type od
design, for instance software engineering platform.
Results obtained from in this study are a first
step in knowledge structuring; we aim at using
classification and aggregation techniques in order to
define typologies of cooperative activity knowledge.
ACKNOWLEDGEMENTS
We thank Champagne Ardennes Region and FEDER
for supporting this work.
REFERENCES
Bekhti, S., Matta, N., Project memory: An approach of
modelling and reusing the context and the design
rationale, Proceedings of IJCAI'03 (International joint
of conferences of Artificial Intelligence) Workshop on
knowledge management and organisational memory,
Acapulco, (2003).
Buckingham Shum S., Representing Hard-to-Formalise,
Contextualised, Multidisciplinary, Organisational
Knowledge. Proceedings of AAI Spring Symposium on
Artificial Intelligence in Knowledge Management, P.9-
16, 1997. http://ksi.cpsc.ucalgary.ca/AIKM97/AI
KM97Proc.html
Castillo O., Matta N. Definition of a practical learning
system. International Conference on Information
Technology Based Higher Education and Training
ITHET 2005, 7-9 July 2005, Saint Domingue. 14 p.
Colin E., Spender J.C., Managerial and organizational
cognition: Theory Methods ans Research, SAGE,
1998.
Diend R., Corby O., Giboin A. and Ribière M., Methods
and Tools for Corporate Knowledge Management, in
Proc. of KAW'98, Banff, Canada. 1998.
Djaiz, C., Matta, N. Project situations aggregation to
identify cooperative problem solving strategies, 10th
International Conference on Knowledge-Based &
Intelligent Information & Engineering Systems,
KES2006, Kuala-Lampur, 2006.
Ducellier G., Charles S., Eynard B., Caillaud E.,
Traceability of simulation data in a PLM
KMIS2013-InternationalConferenceonKnowledgeManagementandInformationSharing
342
Environment: proposition of Step-based system that
support parameter integration, Proceedings of the
International Design Conference – DESIGN’06,
Dubrovnik, Croatia, 15-18 May 2006
Easterby-Smith M., Lyles M. A., Handbook of
Organizational Learning and Knowledge
Management, Blackwell, 2007.
Guarino N., Formal Ontology and Information Systems,
Proceedings of FOIS’98, Trento, Italy, 6-8 June 1998.
Amsterdam, IOS Press, pp. 3-15.
Karsenty, L., An Empirical Evaluation of Design
Rationale Documents, Proceedings of CHI, R. Bilger,
S. Guest, and M. J. Tauber (Eds), (1996).
Klein M., Capturing Design Rationale in Concurrent
Engineering Teams, IEEE, Computer Support for
Concurrent Engineering, January 1993.
Lewkowicz, M., et Zacklad, M. A structured groupware
for a collective decision-making aid. EJOR - special
issue devoted to the Human Processes Conference,
2002, vol. 136, n° 2, p. 333-339.
MacLean A., Young R.M., Bellotti V.M.E., Moran T.P.,
Questions, Options, and Criteria: Elements of Design
Space Analysis, Human-Computer Interaction, Vol.6,
1991.
Matta N., Ermine J-L., Gérard Aubertin, Jean-Yves Trivin,
Knowledge Capitalization with a knowledge
engineering approach: the MASK method, In
proceedings of IJCAI’2001 workshop on Knowledge
Management and Organizational Memory, Seatle,
2001.
Matta N., Ribière M., Corby O., Lewkowicz M., et
Zacklad, M. Project Memory in Design, Industrial
Knowledge Management - A Micro Level Approach.
SPRINGER-VERLAG: RAJKUMAR ROY, 2000.
Matta N., Ducellier G., Charlot Y., Ridha M., Tribouillois
F., Hibon E. Traceability of Design Project
Knowledge using PLM, CTS Conference, 23 - 27
May, Philadelphia, USA, 2011
Nonaka I., Takeuchi H.: The knowledge-Creating
Company: How Japanese Companies Create the
Dynamics of Innovation. Oxford University Press,
1995.
Schreiber G., Wielinga B., Van de Velde W., Anjewierden
A., CML: The CommonKADS Conceptual Modelling
Language, Proceedings of EKAW'94, Lecture Notes in
AI N.867, L.Steels, G. Schreiber, W.Van de Velde
(Eds), Bonn: SpringerVerlag, September 1994, pp.1-
25.
Sudarsan, R., Fenves, S., Sriram, R., & Wang, F. (2005).
A product information modeling framework for
product lifecycle management. Computer-Aided
Design Vol. 37, 1399–1411.
MemoryMeetings-AnApproachtoKeepTrackofProjectKnowledgeinDesign
343
