Management of Project Knowledge and Experience

Journal of Knowledge Management
Management of project knowledge and experiences

Georg Disterer
Article information:
Downloaded by BAHRIA INSTITUTE OF MANAGEMENT & COMPUTER SCIENCE At 03:22 17 April 2016 (PT)
To cite this document:

Georg Disterer, (2002),"Management of project knowledge and experiences", Journal of Knowledge Management, Vol. 6 Iss
5 pp. 512 - 520
Permanent link to this document:
http://dx.doi.org/10.1108/13673270210450450
Downloaded on: 17 April 2016, At: 03:22 (PT)
References: this document contains references to 25 other documents.
To copy this document: [email protected]
The fulltext of this document has been downloaded 5249 times since 2006*
Users who downloaded this article also downloaded:

(2009),"Knowledge management in project environments", Journal of Knowledge Management, Vol. 13 Iss 4 pp. 148-160
http://dx.doi.org/10.1108/13673270910971897
(2004),"Knowledge management benchmarks for project management", Journal of Knowledge Management, Vol. 8 Iss 1 pp.
103-116 http://dx.doi.org/10.1108/13673270410523943
(2010),"Critical factors for knowledge management in project business", Journal of Knowledge Management, Vol. 14 Iss 1
pp. 156-168 http://dx.doi.org/10.1108/13673271011015633
Access to this document was granted through an Emerald subscription provided by emerald-srm:543713 []
For Authors
If you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service
information about how to choose which publication to write for and submission guidelines are available for all. Please
visit www.emeraldinsight.com/authors for more information.
About Emerald www.emeraldinsight.com

Emerald is a global publisher linking research and practice to the benefit of society. The company manages a portfolio of
more than 290 journals and over 2,350 books and book series volumes, as well as providing an extensive range of online
products and additional customer resources and services.
Emerald is both COUNTER 4 and TRANSFER compliant. The organization is a partner of the Committee on Publication
Ethics (COPE) and also works with Portico and the LOCKSS initiative for digital archive preservation.
*Related content and download information correct at time of download.
Management of project
knowledge and
experiences
Georg Disterer
The author
Georg Disterer is Professor, Department of Business
Administration, University of Applied Sciences, Hannover,
Germany.
Keywords
Knowledge management, Project management,
Development
Abstract
Modern organizations have to react fast and be flexible to
innovative and interdisciplinary questions. Therefore
organizing by projects is on a strong increase, because
projects are accepted to be learning intensive
organizational forms. But the boundaries between
projects and the permanent organization are strong
barriers for knowledge and experiences gained in
projects. Knowledge management functions have to
handle the knowledge and experiences from projects.
Electronic access
The current issue and full text archive of this journal is
available at
http://www.emeraldinsight.com/1367-3270.htm

Volume 6 . Number 5 . 2002 . pp. 512520
# MCB UP Limited . ISSN 1367-3270
DOI 10.1108/13673270210450450
Introduction
The importance of excellent performance in
the management of IT projects is growing.
Increasing environmental pressures and
uncertainty, shrinking time frames for IT
projects, decreasing time to market for project
results and high quality requirements make
effective and efficient management of IT
projects a critical success factor of many
companies.
Knowledge and experiences from IT
projects are an important resource for
following projects because IT projects solve
innovative and interdisciplinary tasks. But the
use of project organization and project teams
results in decentralization and knowledge
fragmentation. After finishing the project
team members are spread all over the
company, project documentation is stored in
some folders without retaining the essentials
for later use. But competencies and skills built
up by the members of the project teams
should remain within the companies after the
end of the projects and should be available for
following projects. The broad range of
relevant knowledge and experiences resulting
from projects may be depicted by some
examples:
.
Working experiences with a new software
tool or a new release of a tool, that has
been used for the first time within a
company; this may result in special
knowledge like tips for customizing the
software and useful templates or
experiences about strengths and
weaknesses of the software.
.
Knowledge and insights about business
procedures and dependencies, which are
identified and documented during
analysis and requirements engineering.
.
Knowledge and experiences regarding the
cooperation with external partners (like
suppliers, subcontractors, research
partners etc.) and detailed knowledge
about the cooperating enterprises: special
skills, key competencies, strengths and
weaknesses, timeliness of delivery,
accuracy etc.
Some actions to prevent the loss of knowledge
and experiences are known from the
literature. However, only a few firms manage
systematically to identify and transfer valuable
knowledge from projects to following
projects. ``Project information is rarely
captured, retained, or indexed so that people
512

Volume 6 . Number 5 . 2002 . 512520
Georg Disterer
external to the project can retrieve and apply

it to future tasks'' (Weiser and Morrison,
1998). Evaluation is performed only on a
small fraction of projects, the purpose of
evaluation does not seem to be provision of
improvements in development or project
management practices (Kumar, 1990). Most
firms are not able to evaluate projects and
learn from them. The most simple
consequence of not reviewing a finished
project is that the actions and decisions that
caused problems and errors may be repeated.
For years firms may reject learning from their
mistakes in IT projects. There is a broad
range of reasons: organizational, technical,
methodical issues as well as social problems to
be addressed and discussed (Boddie, 1987;
Abdel-Hamid and Madnick, 1990).
Most of the literature suggests the
introduction of special steps at the end of
projects; some of these steps are shown here.
The article combines the somehow different
perspectives of project management and
knowledge management and highlights actual
issues of IT project management, where
knowledge management means all activities
to understand, focus on, and manage
systematic, explicit, and deliberate knowledge
building, renewal, and application (Wiig,
1997). In recent years knowledge
management has embraced every activity to a
systematical and controlled handling of the
companies' knowledge. The strategic
importance of the resource knowledge
compels companies to intensify and
systematize the management of business
knowledge.
Projects and project organization

In this context, projects and the established
methods and tools of project management
need special attention. Within the routine
organization of an enterprise there are
persistent and well known institutions like
functional groups, departments, plants,
branches where knowledge and experiences
are acquired, stored, and disseminated.
Therefore these institutions can be `àsked''
and knowledge and experiences can be
retrieved regardless of the specific
appearance of the collections, e.g.
documentation, archive, competent employee
or hidden within the working process.
In most simple situations where knowledge

is being asked for this provides fast and
straight forward help: Question: ``Who knows
anything about material abc?'' Answer: ``Go
and ask the colleagues from the plant.'' ``What
route planning systems do we know?'' ``The
colleagues from the logistic department will
know.'' ``. . . there will be documents in our
branch in the East.'' ``. . . Controlling will
know.'' ``. . . there must be some information
in the working procedures . . .''.
Normally, these solutions are not available
for knowledge and experiences, which were
acquired and collected during projects.
Projects are defined as temporary
organizations with specific objectives, detailed
tasks, and restricted time and budget. When a
project is finished, normally there is no
institution or corpus left where existing
knowledge can be accessed. Meeting points
like groups, departments, plants, branches in
the routine organizations no longer exist
after the end of a project. In most cases, even
the place where the documentation of a
specific project is stored will be unknown.
After its end, the organization of the project is
dissolved and no longer exists (see Figure 1).
Additionally, it will be hard to find out
which employees worked on a recently
finished project, who were responsible for
specific tasks, and where these employees are
working now within the company if at all.
Obviously, these kinds of problems will
increase with the number of projects running
in parallel, systematic securing of knowledge
and experiences is even more important in
multi-project management. For better
clearance we will assume here that only one
project at a time runs within a company.
Companies not systematically securing
knowledge gained in projects for later usage
risk that some certain knowledge and useful
experiences get lost with the end of a project.
Traditional project management concentrates
on planning, organization, directing and
controlling resources to achieve specific goals
on time and within budget. Within traditional
project management efficiency and
effectiveness of the work of the project's team
members is critical. The organizational
context of projects and the potential needs of
following projects are not within the focus of
applied project management tactics. Most
companies are investing heavily in innovative
project work but investing nothing in
evaluating and learning from it. Companies
513

Volume 6 . Number 5 . 2002 . 512520
Georg Disterer
Figure 1 Permanent and temporary organization
learn the most within projects, but cannot

pass on their experiences. At best, project
team members keep the knowledge and
experiences as individual knowledge, which
they may use in the future.
The following description points out the
importance of some knowledge management
techniques for project management. Special
issues will be explained and approaches to
acquire, store, and disseminate knowledge
and experiences from projects will be
discussed.
Knowledge transfer between projects

In recent years the number of tasks and the
amount of work within a company, which is
being managed in the form of projects, is
growing very fast. There is no end of this
trend to be seen, because key characteristics
of project organizations address success
factors of companies: high flexibility,
interdisciplinary work, promoting innovation.
Additionally, the need for better project
efficiency increases and the length of projects
becomes more and more important.
Development projects are made urgent by the
influence of ``time-to-market'', internal
projects should show their benefits as soon as
possible. Time pressures can result in some
short term optimization. The phrase
``reinventing the wheel'' stands for such
tactics, where existing knowledge and
experiences cannot be accessed and used,
because these are not stored and
disseminated.
Increasing complexity of project work
caused by a growing number of technical and
social relationships and interfaces to be
considered gives higher value to existing

knowledge in order to deal with complexity
and to increase efficiency. For that reason
projects have to adapt knowledge and
experiences from the daily work of a company
within the routine organization and from
former projects (see Figure 2).
Project team members can be the main
carriers for knowledge and experiences from
daily work, they bring this input into a project
team, e.g. for application development
projects the future users of an application
system. The terms `ùser participation'' and
`ùser involvement'' stand for ways to transfer
knowledge and experiences from users and
functional experts to developers. Also internal
documentation, standard operating
procedures (sop) etc. contains knowledge,
which can be reused in projects. Additional,
experienced users and experts can be
interviewed during requirements analysis. So
the transfer of knowledge from routine
organizations to projects is regarded as well
established.
The transfer of knowledge and experiences
from projects to the routine organization is
explicitly assigned and addressed within the
project management: product documentation
takes this role, for example in the form of a
technical drawing, which is given to the
production department as a part of a technical
solution worked out in a project, or in the
form of users' manual and operating
instructions for an application software,
where knowledge about usage and handling of
the application is documented for users and
system administrators. Training courses and
materials have similar functions to transfer
knowledge about an application from the
developer to the user.
514

Volume 6 . Number 5 . 2002 . 512520
Georg Disterer
Figure 2 Knowledge transfer to and from projects
However, with these tools and techniques

only knowledge and experiences with regards
to the working results of projects can be
stored and disseminated. Prospective readers
are users of project results working in the
routine organization, e.g. users and
administrators of an application system.
In contrast to this, knowledge about
methods and tools used in the project, which
might be useful to other workers in the
routine organization or even more useful
for members of following projects cannot be
transferred with these methods. In parallel,
the transfer of knowledge and experiences
from preceding projects about methods and
tools used should be passed on to following
projects.
Two examples will show some details.
Within a project a firm develops a new
application system, which is based on a very
new technology. During the project team
members get in contact with a research
institute of a university located in a foreign
country. This institute is working on this
specific technology and very productive
cooperation between the institute and the
project is founded. This cooperation is very
valuable for the project, not only because of
the institutes' expertise, but also because of
similar working habits and cultures. The
institute reacts fast and is open minded and
very professional to inquiries;
communications channels between the
institute and the project function very well.
However, what happens at the end of the
project with this knowledge about the contact,
the successful research cooperation, the
contact partners, the communications
channels etc.? How will following projects
know about the institute? Usually the
knowledge concerning the external

cooperation partners, about persons, their
expertise, their technical equipment, ways of
communication and similar details are lost.
Moreover experiences of working together, like
response times, quality of work etc. remain
hidden in the heads of some project team
members and are not identified, evaluated, and
disseminated in a systematic way.
Second example: a new release of a project
management software is being used for the
first time within a firm. There are important
differences of this release to the well known
older one and a significant amount of work is
necessary to get accustomed to the new
version of the tool.
When using the tool it shows up that some
new features are useless, others are very useful
if some special tricks in using them are
known. During the work with the software a
lot of knowledge and experiences with the
software are gained. The team members using
the software know how to handle the software
and they create some smart sheets and
templates, which potentially are useful in
other projects too. But what happens
normally? Traditional transfer methods do
not capture this knowledge and experiences,
employees working on following projects do
not get any benefits from this existing
knowledge. Project documentation does not
contain any of this knowledge, because
project management and steering committees
are addressed, product documentation
addresses users and administrators, not
members of following project teams. Only by
accident, one of the team members familiar
with the project management software
becomes a project member again and can
bring in the necessary skills to handle the
515

Volume 6 . Number 5 . 2002 . 512520
Georg Disterer
software. Otherwise knowledge and

experiences tied to a person get lost in the
companies' organization.
These examples clearly show that
traditional methods usually fail. Only for very
few exceptions like passing some reference
numbers on estimation of costs and efforts
the transfer of knowledge between projects is
established. Traditional project management
aims at planning, organizing, and controlling
project activities to achieve specific goals, the
focus is on efficiency and effectiveness of
every project. When more and more
important work is done within projects,
``professional'' project management should
aim at continuous improvement with every
project (Ayas, 1996), and new questions
appear apart from the project centered
questioning: ``How to organise the relations
between different projects . . .?'' (Lundin and
Miller, 1998).
Product and project documentation

The documentation of projects rarely
contains valuable knowledge for following
projects. The classical target groups of the
documentation are different from members of
future projects. Normally product
documentation for software development
projects addresses the needs of the potential
user and the potential administrator of the
software; therefore the documentation
contains instructions, manuals, drawings etc.
regarding the software. Project
documentation (project folders, project plans,
schedules, cost summaries, progress reports,
protocols etc.) should support
communication during the project and
address the information needs of various
people: project members, project
management, project steering and
supervising.
Thus, the documentation of a project is
rarely meant for members of future projects.
This type of documentation would represent
methods and proceedings, outline precise
problems, describe successful and
unsuccessful solutions, mention persons to
turn to and external experts, contain
descriptions of successful cooperations and
their success factors, hand down handling
tricks etc. In this context especially
descriptions of ``lessons learned'' would be
helpful for following projects.
In the same way it would be extremely

useful in bigger firms to find members of
preceding projects in order to question them.
This may work smoothly within small and
medium companies. In bigger firms it is often
the case, that members of a project finished a
year ago can only hardly be identified and
information about their current workplace
can only be found with considerable effort.
Barriers to knowledge transfer

Normally project work is being pressed by
time and budget restrictions. That is the
reason why most of all projects have to take
the completion of the software as the end of
the project. Necessary work after the
completion of the software like capturing
knowledge and experiences must be
dropped because of missing time resources.
Additionally members of the project team are
needed for other following projects and their
new team leaders will ``pull'' to get them into
the teams as soon as possible. Therefore most
project teams are being dissolved gradually
without the chance for all team members to
systematical rework and document the
knowledge and experiences.
Moreover, considerable individual and
social barriers exist to articulating and
documenting individual knowledge and
experiences (Disterer, 2000, 2001).
Especially analysis of failures and mistakes
would be very valuable, but usually an open
and constructive atmosphere to articulate and
analyze errors is missing. ``The postmortem
experience is much like a losing football team
watching a game film. It's not comfortable,
but if the team pays attention to its mistakes,
it can perform better the next time it plays''
(Boddie, 1987). Because it is not comfortable,
employees avoid admiting mistakes, they are
scared of negative effects for them. But
successful projects can only affirm that the
methods used were sufficient for that specific
task, failed projects need more efforts to
uncover what they can teach (Boddie, 1987).
Obviously other employees within the
company can take advantage of captured
knowledge and experiences in subsequent
projects. But these synergies between
employees of a company can only be
established and developed if all employees are
taking part in this exchange. Most often the
prospective benefit for a single employee is
516

Volume 6 . Number 5 . 2002 . 512520
Georg Disterer
not clear enough and too vague (``What's in it

for me?''). This does not give enough
motivation to document some ``lessons
learned''.
In most companies documentation is not
given enough recognition and appreciation.
Although most methodologies for software
development (and other project work)
recommend special work packages for
securing knowledge and experiences, these
steps are rarely set up and defined in projects.
The result is: why should team members
recognize securing of experience as something
important, even if the project plan does not
designate explicit and enough time resources
for this?
Important implications for project
management are: project phases, working
packages, and tasks designated to identifing
and securing knowledge and experiences are
necessary. Additionally the management of
knowledge and experiences needs an
atmosphere of generosity, freedom and safety,
so that the employees participate in
knowledge sharing. In the following, some
steps are discussed which can foster this
knowledge sharing between projects.
Steps to foster the transfer of

knowledge and experiences
Already during project definition and project
planning working steps and time budgets
dedicated to capturing and transferring
knowledge and experiences must be defined.
Additionally it has to be defined who is going
to be responsible, in which areas is new
knowledge expected, how experiences have to
be documented, stored and preserved.
Recent literature and actual discussions
indicate that project closing is becoming the
most important phase to identify and to
capture new knowledge and to prepare
the knowledge for knowledge transfer to
other projects.
Terms like `èxperience retention'' and
``debriefing'' are pointing out, that this phase
represents an opportunity to identify and
secure knowledge and experiences of project
team members. Other terms give further hints
on the goals:
.
Post project review (Steinle et al., 2000).
.
Post project appraisal (Gulliver, 1987).
.
After action review (Cross and Baird,
2000).
.
.
.
.
.
.
Project postmortem review (Boddie,

1987; Chikofsky, 1990; Collier et al.,
1996; Birk and Tautz, 1998; AbdelHamid and Madnick, 1990).
Debriefing (von Krogh, 1998; Blessing
and Gork, 2000; Collier et al., 1996).
Reuse planning (Fitter, 2000).
Cooperative project evaluation (Lullies et
al., 1993).
Reflection (Steinle et al., 2000).
Corporate feedback cycle (Basili et al.,
1994).
Experience factory (Basili et al., 1994).
Post installation evaluation (Kumar,
1990).
Post implementation evaluation (Kumar,
1990).
Less frequently used terms are post project

control, post project analysis, post completion
review, phasing out. Some important
differences between the various approaches
are that:
.
some prefer to dedicate the review work
to project team members, others prefer
review specialists from outside the
project;
.
all projects have to be reviewed or only
the larger or more important ones;
.
different actions are taken to foster open
and constructive discussion;
.
some approaches aim primarily to
measure the success of the finished
projects, hints for subsequent projects are
``byproducts'';
.
revisions are made together with (or by)
project team members or based on the
analysis of the project documentation.
For example, BP has successfully
supplemented the project methodology with
appropriate tasks for a systematic project
evaluation (Hartman, 1999), similar activities
are reported for Siemens (Schindler, 2000).
Other examples are published for consulting
firms, which obviously have great interest in
the reuse of knowledge and experiences in
their projects. Questions which can initiate
these processes are:
.
How did the project work during the
different project phases?
.
Which factors were critical for the
successful acquisition of a project?
.
Where did we perform well, what can we
do better next time?
.
Where were particular `òbstacles'' during
the project, how did we manage these?
517

Volume 6 . Number 5 . 2002 . 512520
Georg Disterer
.
How was the communication between the

project team members? What has
improved the work progress, what has
hindered it?
How can future planning/organization/
controlling be improved?
Which knowledge and experiences from
the project can we pass on to others?
With phrases like these an active reflection of

the work progress within the project can be
started. A precondition is an open and
constructive atmosphere of generosity,
freedom and safety between the project team
members. Some experiences of a project have
to be looked at critically, so that the persons
involved must keep a distance to their own
doing and must avoid blaming others. In
order to foster these important learning
effects out of critical and somehow
problematic project situations, a trustful and
open working atmosphere has to be created
and secured by the management.
One possible form to capture the result of
such reflection are so called ``lessons learned''.
This special documentation covers the full
and detailed, descriptions of the identification
and the solution of concrete and detailed
explained problems, which can be used as
examples for following projects. The
questions raised and discussed during
reflection and documented in lessons learned
can cover technical issues, organizational
aspects or special social situations. The
description should also include failed
approaches and approaches which are not
chosen for implementation.
Through the detailed description of the
problem and the successful and less successful
ways to a solution, lessons learned are
considered to be a way to reveal and store
implicit knowledge. Implicit knowledge is
mainly acquired through experiences and
embedded in mental models, individual
patterns, values, and insights and is extremely
difficult to codify, document, and transfer to
colleagues. Lessons learned describe one way
to externalize implicit knowledge (Nonaka,
1994).
Another documentation tool for project
knowledge is represented by project profiles
which cover project characteristics and
summaries. Employees having access to the
profiles can browse through or search them.
For example, for a software development
project details should be systematically stored
like: programming environment, production

environment, hardware, system software,
tools, involved functional areas and
departments, team members, participating
employees etc. Overall a systematic collection
of project profiles provide a source of
knowledge about projects and can be used by
others to find people or documents to get
some help or support.
A similar approach picks up the problem
that after the end of a project team members
can only be identified and contacted with
huge efforts. Thus ad hoc inquiries from
members of following projects are prevented.
Therefore databases are created and
implemented, where employees' assignments
to projects are documented and working
experiences can be traced. In this way internal
``yellow pages'' are created (or: `èxpert
registers'', ``who knows what'' databases).
These can be searched by keywords in order
to find a contact person for a specific
problem. The information about project and
working experiences stored in the database is
completed by data about ways of contact such
as current workplace, phone number, e-mail
address etc. in order to assist ad hoc queries.
External experts can also be added to such a
database, e.g. suppliers, consultants, former
employees, if it is possible and acceptable to
contact them with a problem.
Building up yellow pages follows a strategy
of personalization, which states that
important knowledge of a company is strongly
attached to persons (Hansen et al., 1999).
This implicit knowledge can be shared best
through using direct and personal
communication. With this strategy knowledge
is not primarily collected, edited and made
available in documentation and files, but
above all direct communication and
knowledge exchange between people are
fostered. Strictly speaking the strategy of
personalization is not ``really'' about the
management of knowledge, but more about
management of communication between
people.
Additionally, firms can define some
organizational responsibilities for transferring
knowledge and experiences from projects.
SAP recently introduced full time positions
called ``project experience managers'' in order
to anchor knowledge and experiences from
projects to the organization (Blessing and
Gork, 2000). Viant has introduced positions
called ``Catalyst'' for bigger projects, who are
518

Volume 6 . Number 5 . 2002 . 512520
Georg Disterer
responsible for fostering and improvement of

knowledge reuse (Fitter, 2000).
PricewaterhouseCoopers opened the position
``knowledge harvester'' within the project
methodology they use for larger projects. For
half of the 300 projects running this part-time
position of a ``knowledge harvester'' is filled
(DeVoss, 2000).
Conclusion
Today organizing by projects is on a strong
increase, because companies have to address
complex business changes, and modern
organizations have to react fast and be flexible
to innovative and interdisciplinary questions.
Projects are accepted to be knowledge
intensive organizational forms.
However, projects are temporal
organizations and after their end documents
and contact persons are hard to access.
Therefore, the acquired knowledge and
experiences have to be identified, prepared
and distributed through specific actions to
bridge the boundaries between one project
and other projects or the firm's permanent
organization. An important knowledge
management function has to handle the
knowledge and experiences from projects.
Promising activities focus on the closing of
projects, where dedicated and conscious steps
of reflection have to be taken. Therefore a
working atmosphere, which allows open and
constructive discussions must be provided by
management. Additionally systematical
collections of project profiles and contact
persons can support the reuse of knowledge in
other projects. Faster finding of similar
problems or experts for certain questions can
speed up and improve project work.
Moreover a systematical exchange of
knowledge and experiences makes the
acquainting of a new employee considerably
easier.
`Èffective application of traditional project
management tools is necessary but no longer
sufficient'' (Ayas, 1996). The success of
projects depends heavily on the right
combination of knowledge and experiences,
therefore dissemination and usage of existing
knowledge is critical. Companies must spend
sustainable learning efforts not only for one
project, but for the future of the company.
Failures must be seen as opportunities to
improve rather than to blame people involved.
Therefore the basic tasks of project

management must be supplemented by
important activities of knowledge
management.
References
Abel-Hamid, T.K. and Madnick, S.E. (1990), ``The elusive
silver lining: how we fail to learn from software
development failures'', Sloan Management Review,
Vol. 32 No. 3, pp. 39-48.
Ayas, K. (1996), ``Professional project management: a shift
towards learning and a knowledge creating
structure'', International Journal of Project
Management, Vol. 14 No. 3, pp. 131-6.
Basili, V.R., Caldiera, G. and Rombach, H.D. (1994),
`Èxperience factory'', in Marciniak, J.J. (Ed.),
Encyclopedia of Software Engineering, Vol. I, Wiley,
New York, NY, pp. 469-76.
Birk, A. and Tautz, C. (1998), ``Knowledge management of
software engineering lessons learned'', Proceedings
10th Conference on Software Engineering and
Knowledge Engineering, Knowledge Systems
Institute, Skokie/IL, San Francisco, CA, pp. 116-19.
Blessing, D. and Gork, M. (2000), ``Management von
Projekterfahrungswissen bei der SAP AG'',
Information Management & Consulting, Vol. 15
No. 3, pp. 49-53.
Boddie, J. (1987), ``The project postmortem'',
Computerworld, 7 December, p. 7.
Chikofsky, E.J. (1990), ``Changing your endgame
strategy'', IEEE Software, Vol. 7 No. 6, pp. 87f.
Collier, B., DeMarco, T. and Fearey, P. (1996), `À defined
process for project postmortem review'', IEEE
Software, Vol. 13 No. 4, pp. 65-72.
Cross, R. and Baird, L. (2000), ``Technology is not enough:
improving performance by building organizational
memory'', Sloan Management Review, Vol. 41
No. 2, pp. 69-78.
DeVoss, D. (2000), ``Knowledge harvesters dig deep'',
Knowledge Management Magazine, p. 8.
Disterer, G. (2000), ``Social barriers for knowledge
databases in professional service firms'', in
Khosrowpour, M. (Ed.), Challenges of ITManagement in the 21st Century Proceedings of
IRMA 2000 Conference, Idea, Hershey-London,
pp. 1088-89.
Disterer, G. (2001), `Ìndividual and social barriers to
knowledge transfer'', in Sprague, R.H. (Ed.),
Proceedings of 34th Hawaii International
Conference on System Sciences, IEEE, Los Alamitos,
CA, et al., pp. 1-7.
Fitter, F. (2000), ``Catalysts for knowledge'', Knowledge
Management Magazine, p. 7.
Gulliver, F.R. (1987), ``Post-project appraisals pay'',
Harvard Business Review, Vol. 65 No. 2, pp. 128-32.
Hansen, M.T., Nohria, N. and Tierney, T. (1999), ``What's
your strategy for managing knowledge'', Harvard
Business Review, Vol. 77 No. 2, pp. 106-16.
Hartman, C.P. (1999), `Ìnterview with Michael Earl: CKOs
who are they and what do they do?'', Knowledge
Edge, Vol. 1 No. 1, pp. 16-21.
519
Georg Disterer

Volume 6 . Number 5 . 2002 . 512520
Kumar, K. (1990), ``Post implementation evaluation of

computer-based information systems: current
practices'', Communications of the ACM, Vol. 33
No. 2, pp. 203-12.
Lullies, V., Bollinger, H. and Weltz, F. (1993),
Wissenslogistik Uber den betrieblichen Umgang
mit Wissen bei Entwicklungsvorhaben, Campus,
Frankfurt-New York, NY.
Lundin, R.A. and Midler, C. (1998), `Èvolution of project
as empirical trend and theoretical focus'', in Lundin,
R.A. and Midler, C. (Eds), Projects as Arenas for
Renewal and Learning Processes, Kluwer, Boston,
MA, pp. 1-9.
Nonaka, I. (1994), `À dynamic theory of organizational
knowledge creation'', Organization Science, Vol. 5
No. 2, pp. 14-37.
Schindler, M. (2000), Wissensmanagement in der

Projektabwicklung, Eul, Lohmar-Koln.
Steinle, C., Eickhoff, M. and Vogel, M. (2000),
``Vitalisierung von Unternehmen durch
organisationales Lernen in Projekten'', in Steinle, C.,
Eggers, B., Thiem, H. and Vogel, B. (Eds),
Vitalisierung, FAZ, Frankfurt, pp. 277-93.
von Krogh, G. (1998), ``Care in knowledge creation'',
California Management Review, Vol. 40 No. 3,
pp. 133-53.
Weiser, M. and Morrison, J. (1998), ``Project memory:
information management for project teams'',
Journal of Management Information Systems,
Vol. 14 No. 4, pp. 149-66.
Wiig, K.M. (1997), ``Knowledge management: where did it
come from and where will it go?'', Expert Systems
with Applications, Vol. 13 No. 1, pp. 1-14.
520
This article has been cited by:

1. Bastian Ekrot, Alexander Kock, Hans Georg Gemnden. 2016. Retaining project management competence Antecedents
and consequences. International Journal of Project Management 34, 145-157. [CrossRef]
2. Kweku-Muata Osei-Bryson, Corlane BarclayDecision Style Profiles of Project Managers: Preliminary Exploration of Idea
versus Action Orientation 31-46. [CrossRef]
3. Corlane BarclayKnowledge Management Practices in Temporary Organizations 229-248. [CrossRef]
4. Marija Lj. Todorovi, Dejan . Petrovi, Marko M. Mihi, Vladimir Lj. Obradovi, Sergey D. Bushuyev. 2015. Project success
analysis framework: A knowledge-based approach in project management. International Journal of Project Management 33,
772-783. [CrossRef]
5. Paul Ihuoma Oluikpe Strategy Management Department, Central Bank of Nigeria, Abuja, Nigeria . 2015. Knowledge creation
and utilization in project teams. Journal of Knowledge Management 19:2, 351-371. [Abstract] [Full Text] [PDF]
6. Kweku-Muata Osei-Bryson, Corlane BarclayDecision Making and Decision Styles of Project Managers: A Preliminary
Exploration Using Data Mining Techniques 259-278. [CrossRef]
7. Menoka Bal, David Bryde. 2015. Measuring Performance to Engage the Extended Project Team in Construction. Journal of
Construction Engineering and Project Management 5, 1-10. [CrossRef]
8. Anna Corinna Cagliano, Sabrina Grimaldi, Carlo Rafele. 2015. Choosing project risk management techniques. A theoretical
framework. Journal of Risk Research 18, 232-248. [CrossRef]
9. Dali Zhao, Meiyun Zuo, Xuefei (Nancy) Deng. 2015. Examining the factors influencing cross-project knowledge transfer:
An empirical study of IT services firms in China. International Journal of Project Management 33, 325-340. [CrossRef]
10. Stephen Duffield, S. Jonathan Whitty. 2015. Developing a systemic lessons learned knowledge model for organisational
learning through projects. International Journal of Project Management 33, 311-324. [CrossRef]
11. D. Oehme, R. Riedel, E. MullerModular, building blocks — Based approach for information and documentation
management in planning projects 428-432. [CrossRef]
12. Gillian Ragsdell, Eva Ortoll Espinet, Michael Norris. 2014. Knowledge management in the voluntary sector: a focus on
sharing project know-how and expertise. Knowledge Management Research & Practice 12, 351-361. [CrossRef]
13. Phil Crosby. 2014. Building Resilience in Large High-Technology Projects. International Journal of Information Technology
Project Management 3:10.4018/IJITPM.20121001, 21-40. [CrossRef]
14. Ali Mohammed Alashwal, Hamzah Abdul-Rahman. 2014. Using PLS-PM to model the process of inter-project learning in
construction projects. Automation in Construction 44, 176-182. [CrossRef]
15. Ali Mohammed Alashwal Quantity Surveying, University of Malaya, Kuala Lumpur, Malaysia Hamzah Abdul-Rahman
International University of Malaya-Wales, Kuala Lumpur, Malaysia . 2014. Aspects of project learning in construction: a
socio-technical model. Construction Innovation 14:2, 229-244. [Abstract] [Full Text] [PDF]
16. Morteza Shokri-Ghasabeh PhoenixPM, Mile End, Australia Nicholas Chileshe School of Natural and Built Environments,
University of South Australia, Adelaide, Australia . 2013. Knowledge management. Construction Innovation 14:1, 108-134.
[Abstract] [Full Text] [PDF]
17. Nicola KellyUniversity College London, London, UK Andrew John EdkinsUniversity College London, London, UK Hedley
SmythUniversity College London, London, UK Efrosyni KonstantinouUniversity College London, London, UK. 2013.
Reinventing the role of the project manager in mobilising knowledge in construction. International Journal of Managing
Projects in Business 6:4, 654-673. [Abstract] [Full Text] [PDF]
18. Kam JugdevAthabasca University, St Albert, Canada Gita MathurSan Jos State University, San Jos, California, USA. 2013.
Bridging situated learning theory to the resourcebased view of project management. International Journal of Managing Projects
in Business 6:4, 633-653. [Abstract] [Full Text] [PDF]
19. Varintorn Supyuenyong, Fredric William Swierczek. 2013. Knowledge Management Process and Organizational Performance
in SMEs. International Journal of Knowledge Management 7:10.4018/jkm.20110401, 1-21. [CrossRef]
20. Patricia Carrillo, Kirti Ruikar, Paul Fuller. 2013. When will we learn? Improving lessons learned practice in construction.
International Journal of Project Management 31, 567-578. [CrossRef]
21. Vera Bartsch, Mark Ebers, Indre Maurer. 2013. Learning in project-based organizations: The role of project teams' social
capital for overcoming barriers to learning. International Journal of Project Management 31, 239-251. [CrossRef]
22. Primali Paranagamage, Patricia Carrillo, Kirti Ruikar, Paul Fuller. 2012. Lessons learned practices in the UK construction
sector: current practice and proposed improvements. Engineering Project Organization Journal 2, 216-230. [CrossRef]
23. Hamzah Abdul-Rahman, Chen Wang, Shamini Batu Malay. 2012. Structured project learning model toward improved
competitiveness in bidding for large construction firms. Journal of Civil Engineering and Management 18, 546-556. [CrossRef]
24. Grant KululangaCivil Engineering, University of Malawi, Blantyre, Malawi. 2012. Capacity building of construction industries
in SubSaharan developing countries. Engineering, Construction and Architectural Management 19:1, 86-100. [Abstract] [Full
Text] [PDF]
25. Frank Lindner, Andreas Wald. 2011. Success factors of knowledge management in temporary organizations. International
Journal of Project Management 29, 877-888. [CrossRef]
26. Patricia Carrillo, Jenny Harding, Alok Choudhary. 2011. Knowledge discovery from post-project reviews. Construction
Management and Economics 29, 713-723. [CrossRef]
27. Marco Formentini, Pietro Romano. 2011. Using value analysis to support knowledge transfer in the multi-project setting.
International Journal of Production Economics 131, 545-560. [CrossRef]
28. Stanisaw Gasik. 2011. A model of project knowledge management. Project Management Journal 42:10.1002/pmj.v42.3, 23-44.
[CrossRef]
29. Mostafa JafariDepartment of Industrial Engineering, Iran University of Science and Technology (IUST), Tehran, Iran Jalal
RezaeenourDepartment of Industrial Engineering, Industrial University of Science and Technology, Tehran, Iran Mohammad
Mahdavi MazdehDepartment of Industrial Engineering, Iran University of Science and Technology (IUST), Tehran, Iran
Atefe HooshmandiDepartment of Management, University of Tehran, Tehran, Iran. 2011. Development and evaluation of
a knowledge risk management model for projectbased organizations. Management Decision 49:3, 309-329. [Abstract] [Full
Text] [PDF]
30. Pietro Romano, Marco Formentini, Camillo Bandera, Marco Tomasella. 2010. Value analysis as a decision support tool in
cruise ship design. International Journal of Production Research 48, 6939-6958. [CrossRef]
31. YULIA STUKALINA. 2010. The Management of Integrated Educational Environment Resources: the factors to be
considered. European Journal of Education 45:10.1111/ejed.2010.45.issue-2, 345-361. [CrossRef]
32. References 171-185. [CrossRef]
33. A.K. Choudhary, P.I. Oluikpe, J.A. Harding, P.M. Carrillo. 2009. The needs and benefits of Text Mining applications on
Post-Project Reviews. Computers in Industry 60, 728-740. [CrossRef]
34. Mian M. AjmalDepartment of Production, University of Vaasa, Vaasa, Finland Tauno KekleDepartment of Production,
University of Vaasa, Vaasa, Finland Josu TakalaDepartment of Production, University of Vaasa, Vaasa, Finland. 2009. Cultural
impacts on knowledge management and learning in projectbased firms. VINE 39:4, 339-352. [Abstract] [Full Text] [PDF]
35. Dean A. Shepherd, Melissa S. Cardon. 2009. Negative Emotional Reactions to Project Failure and the Self-Compassion to
Learn from the Experience. Journal of Management Studies 46:10.1111/joms.2009.46.issue-6, 923-949. [CrossRef]
36. Carlos H. Caldas, G. Edward Gibson, Runi Weerasooriya, Angela M. Yohe. 2009. Identification of Effective Management
Practices and Technologies for Lessons Learned Programs in the Construction Industry. Journal of Construction Engineering
and Management 135, 531-539. [CrossRef]
37. S. SenaratneDepartment of Building Economics, University of Moratuwa, Sri Lanka M.G. SextonResearch Institute for the
Built and Human Environment, School of Built Environment, University of Salford, Salford, UK. 2009. Role of knowledge
in managing construction project change. Engineering, Construction and Architectural Management 16:2, 186-200. [Abstract]
[Full Text] [PDF]
38. Tuula Lehtimki, Henri Simula, Jari Salo. 2009. Applying knowledge management to project marketing in a demanding
technology transfer project: Convincing the industrial customer over the knowledge gap. Industrial Marketing Management
38, 228-236. [CrossRef]
39. Project Knowledge Management Organizational Design and Success Factors - An Empirical Study in Germany 1-14.
[CrossRef]
40. I. Dikmen, M.T. Birgonul, C. Anac, J.H.M. Tah, G. Aouad. 2008. Learning from risks: A tool for post-project risk
assessment. Automation in Construction 18, 42-50. [CrossRef]
41. Jerry Julian. 2008. How project management office leaders facilitate cross-project learning and continuous improvement.
Project Management Journal 39, 43-58. [CrossRef]
42. Ahmed ObaideManagement of project knowledge and experiences: The role of technologies and social processes 1-5.
[CrossRef]
43. Aybke Aurum, Farhad Daneshgar, James Ward. 2008. Investigating Knowledge Management practices in software
development organisations An Australian experience. Information and Software Technology 50, 511-533. [CrossRef]
44. Terry Williams. 2008. How Do Organizations Learn Lessons From Projects—And Do They?. IEEE Transactions on
Engineering Management 55, 248-266. [CrossRef]
45. Mian M. Ajmal, Kaj U. Koskinen. 2008. Knowledge transfer in project-based organizations: An organizational culture
perspective. Project Management Journal 39, 7-15. [CrossRef]
46. Annika Andersson, Henrik C.J. Linderoth. 2008. Learn not to learna way of keeping budgets and deadlines in ERP projects?.
Enterprise Information Systems 2, 77-95. [CrossRef]
47. Ingeborg Knauseder, PerErik Josephson, Alexander Styhre. 2007. Learning approaches for housing, service and infrastructure
project organizations. Construction Management and Economics 25, 857-867. [CrossRef]
48. Weiguo Tang, Alan Olifent, Rajat Roy, Bernhard BehrensDevelopment of a Generic Measurement Point System to Improve
the Dimensional Control Processes in Automotive Body-In-White Manufacturing . [CrossRef]
49. L. DooleyCentre for Enterprise Management, School of Engineering, University of Dundee, Dundee, UK G.
LuptonDepartment of Industrial Engineering and Information Systems, National University of Ireland, Galway, Ireland D.
O'SullivanComputer Integrated Manufacturing Research Unit (CIMRU), National University of Ireland, Galway, Ireland.
2005. Multiple project management: a modern competitive necessity. Journal of Manufacturing Technology Management 16:5,
466-482. [Abstract] [Full Text] [PDF]
50. Patricia CarrilloDepartment of Civil and Building Engineering, Loughborough University, Loughborough, Leicestershire,
UK. 2005. Lessons learned practices in the engineering, procurement and construction sector. Engineering, Construction and
Architectural Management 12:3, 236-250. [Abstract] [Full Text] [PDF]
51. Michel J. LeseureMichel J. Leseure, Lecturer, Operations and Information Management Group, Aston Business School,
Birmingham, UK ([email protected]).Naomi J. BrookesNaomi J. Brookes, Advanced Management Research Centre,
Cranfield School of Management, Cranfield, UK ([email protected]).. 2004. Knowledge management benchmarks for project
management. Journal of Knowledge Management 8:1, 103-116. [Abstract] [Full Text] [PDF]
52. J. Ward, A. AurumKnowledge management in software engineering - describing the process 137-146. [CrossRef]
53. Andrew Booth, Anthea Sutton, Louise Falzon. 2003. Working together: supporting projects through action learning*. Health
Information and Libraries Journal 20:10.1111/hir.2003.20.issue-4, 225-231. [CrossRef]
54. Varintorn Supyuenyong, Fredric William SwierczekKnowledge Management Process and Organizational Performance in SMEs
77-98. [CrossRef]
55. Khairul Shafee B Kalid, Mohd Syafiq SaifullahProject Story Capturing System 315-325. [CrossRef]

Management of Project Knowledge and Experience

Uploaded by

Copyright:

Available Formats

Management of Project Knowledge and Experience

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Management of Project Knowledge and Experience

Uploaded by

Copyright:

Available Formats

Journal of Knowledge Management